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PREFACE 


This is one of two books that describe, at the implementation level, the Systems Network Archi- 
tecture (SNA) logical unit (LU) type 6.2 protocols. This book concerns the SSCP-dependent LU 
6.2 protocols (those protocols involving mediation by a system services control point during 
LU-LU session initiation); the second book, SNA LU 6.2 Reference: Peer Protocols, $SC31-6808, 
concerns the SSCP-independent LU 6.2 protocols. ~LU-LU. protocols not related to 
session-initiation and -termination are common to both SSCP-dependent and -independent LU 6.23 
these common protocols will be updated in the future only in the SNA LU 6.2 Reference: Peer 


Changes from the SC30-3269-1 version of this book are indicated by change bars in the left-hand 
margin. These changes include specification of security provisions at the session and trans- 
action level; additional details of the logic for resynchronizing logical units of work follow- 
ing LU or session failures; and minor enhancements, corrections, and editorial improvements. 
The changes for the security capabilities are extensive, affecting Chapters 2-4, 5.0-5.2, 5.4, 
and 6.1, as well as Appendixes A, E» G, and H. The resynchronization logic is confined to Chap- 
ter 5.3. 


This book does not describe any specific machines or programs that may implement SNA, nor does 
1t describe any implementation-specific su ets or deviations from the architectural description 
that may appear within any IBM SNA product. These matters, as well as information on SNA prod- 
uct installation and system definition, are described in the appropriate publications for the 
particular IBM SNA machines or programs to le used. 


The following books should be read in conjunction with this one. 


COREQUISITE PUBLICATIONS 


e SNA LU 6.2 Reference: Peer Protocols, $C31-6808—reference information on SSCP-independent 


RENN «IAIN 


protocols for LU 6.2. 


e SNA Transaction Programmer's Reference Manual for LU Type 6.2, GC30-3084—reference informa- 
tion on LU type 6.2 verbs for programmers writing transaction programs to run on SNA. 


® SNA Formats, GA27-3136—uinformation on LU 6.2 and other SNA formats. 


PREREQUISITE PUBLICATIONS 


e SNA Concepts and Products, GC30-3072—basic information on SNA for those readers wanting 
either an overview or a foundation for further study. 


@ SNA Technical Overview, GC30-3073—additional details on SNA, especialiy on functions and 
control sequences; bridges the gap between the most elementary overview of SNA and the 
detailed descriptions of the formats and protocols. 


RELATED PUBLICATIONS 


¢ SAA Common Programming Interface: Communications Reference, SC26~4399—description of Sys- 
tems Application Architecture's? Communications Interface, which provides a high-level pro- 
gramming interface to LU 6.2. 


1 Systems Application Architecture is a trademark of International Business Machines Corpo- 
ration. , 
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e SNA Format and Protocol Reference Manual: Architectural Logic, SC30-3112—comprehensive 
information on the formats and protocols of SNA type 1, 2.0, 4» and 5 nodes. 


e SNA—Sessions Between Logical Units, 6GC20-1868—reference information on SNA formats and 
protocols for LU types other than type 6.2. 


e SNA Type 2.1 Node Reference, SC30-3422—reference information on type 2.1 node protocols. 
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CHAPTER 1. INTRODUCTION 
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This book, in conjunction with the companion 
books listed in the Preface, provides a 
formal definition of Systems Network Archi- 
tecture (SNA). It 1s intended to complement 
individual SNA product publications, but not 
to describe individual product implementa- 
tions of the architecture. 


SNA logical unit type 6.2 (hereafter general- 
ly referred to as LU 6.2, or simply LU) is 
defined here in the form of a functionally 
layered system, represented by a formal 
description, that is decomposable into compo- 
nents called protocol machines. Protocol 
machines generate output sequences mn 
response to input sequences, in accordance 
with fixed rules, or protocols, governing 
distinct information transfers into, out of, 
and within the system. 


The protocol machine definition of SNA uses 
the following basic notions: 


® FEinite-state machines: A_ finite-state 
machine (FSM) is an abstract device hav- 
ing a finite number of states (memory) 
and a set of rules whereby the machine's 
responses (state transitions and output 
sequences) to all input sequences are 
well defined. 


®* Routing and checking loqic: Routing and 
checking logic performs a mapping of 
inputs (message units and FSM states) 
into outputs. It is used to verify 
validity of message units and to route 
them to FSMs. 


® Block diagrams: A block diagram repres- 
ents the decomposition of a protocol 
machine into its component submactines 
(which themselves are protocol machines) 
and the signaling paths between them. 
Each block in the diagram can be further 
decomposed into its constituent subma- 
chines. 


° Protocol boundaries: A protocol boundary 
is a specification of the format and con- 


tent requirements imposed on the signals 
exchanged between protocol machines. 


The rematnder of the book presents details of 
the SNA formats and protocols for LU 6.2, 
arranged as follows: 


* Chapter 2 provides an overvien of the 
functions and structure of the LU, as 
well as the sequences and message units 
exchanged between two communicating LUs. 

e Chapters 3 and 4 describe LU services 
manager components; these components 
attach transaction programs as requested, 
allocate sessions to transaction = pro- 
grams, and coordinate the activation and 
deactivation of sessions involving LUs. 


e Chapters 5.0 through 5.4 describe the 
general structure and detailed functions 
of presentation services—in particular 
the execution logic for LU 6.2 verbs. 


¢ Chapter 6.0 provides an overview of the 
half-session, while Chapters 6.1 and 6.2 
describe the data flow control and trans- 
mission control protocols, respectively, 
within half-sessions. 


® Appendix A describes the data structures 
used tn the formal description and the 
relationships among the control blocks. 


¢ Appendixes D through I provide details of 
the general data stream and various head- 
ers, request-response units, profiles; 
and sense data used in SNA. 


¢ Appendix N describes the basic concept 
of, and notation = for, finite-state 
machines. 


¢ Appendix T Cincluded as foldout pages at 
the back of the book) provides a compre- 
hensive list of abbreviations and acro- 
nyms used in the book. 
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Figure I-1. Overview of the SNA Network 
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GENERAL CONCEPTS 


DEFINITION OF AN SNA NETWORK 


An SNA network: 


® Enables the reliable transfer of data 
between end users (typically, terminal 
operators and application programs). 


® Provides protocols for controlling the 
resources of any specific network config- 
uration. 


An SNA network consists logically of a set of 
network addressable units (NAUs) intercon- 
nected by an inner path control network con- 
sisting of the path control, data link 
control, and physical layers; Figure 1-1 on 
page 1-2 shows the general relationships. 
SNA networks functionally have ai layered 
organization, the outermost layers of which 
form the NAUs, each of which in a general SNA 
network is associated with a network address 
(na). A NAU consists of the upper layers, 
transaction services (TS) and presentation 
services (PS), and one or more half-session 
protocol machines (consisting of the data 
flow control and transmission control layers) 
depending on the number of other NAUs with 
which it can be paired to form sessions. 


Those NAUs serving end users are called log- 
ical units (LUs). An LU allows an end user 
to gain access to network resources (such as 
links, programs, and directories) and to com- 
mumicate with other end users. An LU may 
also provide a service (such as for a control 
operator) wholly contained within the LU that 
is accessed from another LU via a session. 
Thus, in some cases, an LU-LU session has an 
end user only at one end. The presence of 
various services within an LU is a function 
of LU type, product design, and installation 
options. 


In general, there need not be a one-to-one 
relationship between end users and LUs. The 
association between end users and the set of 
LUs is an implementation design option. 


The LUs provide protocols allowing end users 
to communicate with each other and with other 
NAUs in the network. An LU can be associated 
with more than one network address (or with 
wultiple, distinct local-form session identi- 
fiers); this allows tro LUs (and therefore 
their end users) to form multiple, concur- 
rently active sessions with each other. 


Besides LUs, two other network addressable 
units are defined: physical units (PUs) and 
system services control points (SSCPs). 
These NAUs, in conjunction with one another 
and with LUs, provide a variety of session, 
configuration, management,» and 
network-operator services. 


Message units are transported between NAUs by 
the path control network. Thase message 
units ara of the general form: 


MSG = (naj ,nai,other parameters, and data), 


where naj is an address of the destination 
NAU, and nat that of the origin NAU. (The 
pair, naj and nai, together identify a par- 
ticular session; their form varies depending 
on the types of nodes involved.) The path 
control network routes and delivers message 
units to naj in the same order as sent from 
nai. 


The message units transferred within an SNA 
network generally have two components: 
end-user information and control information. 
The end-user information is passed by the SNA 
network and does not affect its state. Con- 
trol information may sometimes be passed to 
the end users (as in the case of the Change 
Direction indication, which allows one end 
user to transfer the right to transmit data 
to the other); however, its main purpose is 
to change the state of the SNA network, thus 
effecting a normal contrel change (such as a 
change to a path control routing table) or a 
recovery from an exception condition. 


NODES 


The SNA network physically consists of nodes 
interconnected via links. An SNA node is a 
grouping of SNA-defined protocol machines. 
An SNA product node may consist of addi- 
tional, product-specific protocol machines 
that use one or ~wmore SNA _ nodes. A 
user-application node may consist of addi- 
tional, installation-defined protocol 
machines that use one or more SNA product 
nodes. These relationships are shown in Fig- 
ure 1-2 on page 1-4. The abstraction of 
nested nodes is a useful reminder that each 
product exists in an environment that con- 
tains many design features that are not 
defined by SNA. 


For specific details of nesting of SNA nodes 
and SNA product nodes within user-application 
nodes, see SNA Concepts and Products and SNA 


Technical Overview. 


In this book, "node" is synonymous with "SNA 
node," and the qualifier will generally be 
omitted, Thus, end users and = protocol 
machines not defined im SNA are external to 
the node, as that term is used hereafter. 


Various node types are defined in SNA: types 
1, 2.0, 2.1, 4 and 5. They are distin- 
guished by varying capabilities, such as for 
interconnection, and by the presence or 
absence of different NAU types. 


For example, type 2.1 nodes can connect to 
the general subarea routing netnork or to 
other type 2.1 nodes directly. In the former 
case, subarea nodes (discussed below) provide 
general intermediate routing within the path 
control layer, allowing complex network con- 
figurations to be fashioned; in the latter 
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Examples of Nested Nodes 


case, two type 2.1 nodes can interconnect 
independently of other nodes » in oa 
peer-to-peer relationship. 


Type 1 and type 2 (i.e., 2.0 or 2.1) nodes 
are also referred to as peripheral nodes, 
because they have limited addressing and 
path-control routing capabilities. They do 
not participate in the general network rout- 
ing based on a global network address space. 
Instead, they depend on "boundary function" 
support in types 4 or 5 nodes to transform 
between the address forms, local to the 
peripheral nodes, and the network addresses 
used in the general routing portion of the 
path control network. Peripheral nodes are 


a User-Application Node 


thereby insulated from changes in the global 
network address space resulting from reconf- 
igurations. 


Types 4 and 5 nodes are referred to as sub- 
area nodes. (A subarea represents a parti- 
tioning of the network address space. It 
contains a subarea node and all the peripher-~ 
al nodes attached to the subarea node.) Sub- 
area nodes, besides also being sources and 
Sinks of data, have more general path control 
capabilities. They can perform intermediate 
routing—passing message units received from 
one node on to another—and provide adaptive 
control of traffic flow within the subarea 
routing portion of the network. 
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NAUS AND NODE TYPES 


A node always includes a physical unit (PU), 
which controls the attached Links and various 
other resources of the node. A PU has a type 
designation corresponding to the type (1; 
2.0, 2.1, 4 or 5) of node in which it 
resides. 


A node typically also includes logical units 
(LUs), through which end users attach to the 
node, and thus to the SNA network. From the 
vantage of this book, node types 2.1 and 5 
are of primary interest, as these are the 
only nodes that include LU 6.2 implementa- 
tions. 


A subarea PU or subarea LU resides in a sub- 
area node. A peripheral PU or peripheral LU 
resides in a peripheral node. 


Type 5 nodes each contain a system services 
control point (SSCP). (Type 4 nodes do 
not—the primary architectural distinction 
between subarea node types.) An SSCP sup- 
ports protocols for management and control of 
a domain. <A domain consists of one SSCP and 
the PUs, LUs, links, and link stations that 
the SSCP can activate. Each PU, LU, link, 
and link station in a network belongs to one 
of the domains comprising the network, and 
some can belong to more than one domatn—a 
feature referred to as "shared control." 
Each SSCP provides network services within 
its domain (basically for converting local 
names to global addresses) through protocols 
supported in conjunction with the PUs or LUs 
in the domain. The multiple SSCPs in a net- 
work jointly support network services across 
domains. 


Type 2.1 nodes each contain a peripheral node 
control point (PNCP), which provides services 
on a more local scale than an SSCP provides. 
In particular, a PNCP can mediate LU-LU 
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This section describes some notational con- 
ventions widely used tn both the figures and 
the text. (Additional conventions are 
defined within figure legends throughout the 
book. ) 


A naming convention, using qualifiers sepa- 
rated by periods to denote more specific com- 
ponents of a composite protocol machine, is 
used throughout the book. Component subma- 
chines are shown as blocks within a larger 
block that represents the composite machine. 


In many cases, it 18 desirable to identify a 
qualifier by a phrase of multiple terms, in 
order to better convey the meaning of the 
qualifier. The multiple terms in the phrase 
are connected by underscores to indicate that 
they are part of a phrase rather than sepa- 
rate qualifiers representing further decom- 


session-initiation requests (by doing local 
address look-up) in the type 2.1 node 
peer-to-peer context just as an SSCP does in 
the more general network configuration con- 
text. 


THE PATH CONTROL NETWORK 


The system consisting of all interconnected 
path control (PC) and data link control (DLC) 
components forms the path control network. 
The input/output streams of the path control 
network consist of streams of control infor- 
mation, such as addresses, and associated 
user data. 


Each node has a PC element and NAUs. The 
node and link connections of the network, and 
the PC routing algorithms, combine to provide 
the following behavior for the path control 
network : 


° An input to a PC element in node-1 from a 
NAU is transmitted and routed by the path 
control network and emitted as output by 
the PC element in node-j to the destina- 
tion NAU. (Since node-1 and node-j can 
be the same node (1=}3), NAUs within the 
same node can be connected by a session.) 


sd Message units with the same session iden- 
tifiers are emitted by the path control 
network in the order submitted by the 
origin NAU. 


Just as primary-secondary DLC asymmetries and 
other DLC details are hidden from PC, so the 
routing and other concerns of the path con- 
trol network are not visible at the protocol 
boundary with the NAUs; in particular, the 
path control network conceals the node inter- 
connections and the NAUs need only consider 
their logical connections (1.e., sessions) 
with other NAUs. 


positions. The underscore convention is also 
used in names of states and data structures. 


Each protocol machine in the book has a 
unique name consisting of a sequence of qual- 
ifiers. For example, (MACHINE.PRI.X_SEND, 
MACHINE.SEC.X_RCV) and (MACHINE.SEC.X_SEND, 
MACHINE.PRI.X_RCV) are examples of two basic 
protocol machine pairs. This naming conven- 
tion produces protocol machine names that 
carry precise information on the role of the 
protocol machine and its relative position in 
the network structure. 


Two other symbols, "I" and -"&,"" are used in 
names and expressions. The "|" symbol indi- 
cates one of several (or "either...or''). For 
example, MACHINE.(PRIISEC) means "either 
MACHINE.PRI or MACHINE.SEC.'' The '"'&"' symbol 
is used to indicate composition. For exam- 
ple, MACHINE.(RCV&SEND) is the composite pro- 


Chapter 1. Introduction 1-5 


1-6 


tocol machine consisting of MACH INE.RCV and 
MACHINE .SEND. 


Some of the protocol machines defined in the 
book interact directly with undefined compo- 
nents. These undefined components, called 


undefined protocol machines (UPMs), represent 


implementation and/or installation options 
that are not architecturally prescribed (be- 
ing product or user oriented). 


Within block diagrams, the following con- 
ventions indicate the type of interaction 
between components: 


® Solid arrows indicate data flow; between 
processes, this implies  send/receive 
(asynchronous) logic. 


® Dotted arrows indicate calling relation- 
ships. 


® Dotted lines indicate data structure 
access. 


Message units exchanged between SNA compo- . 


nents are also denoted by special notation, 
particularly in sequence flow diagrams. A 
message unit is either a request or a 
response, depending on the RH coding (see 
"Appendix D. RH Formats'); these are denoted 
respectively by a request-unit name (here 


designated generically by the term "RQ"") and 
by RSP. 


RQ( QUAL) denotes a request having the proper- 
ty described by QUAL; for example, RQ(Begin 
Chain), or simply RQ(BC), denotes a request — 
whose RH is coded "Begin Chain." A similar 
convention applies to responses. For exam- 
ple, RSP(BIND) denotes a response to the BIND 
request—a response that echoes the request 
code "BIND." 


The asterisk (*) character is used in 
sequence flows, as well as elsewhere, to mean 
"any value" (or "don't care"). For example, 
"¥BC'' means "BC or -BC''—where "-" jis the 
standard symbol for "NOT." 


The procedural logic in the formal 
description uses simple English, some 
control-structure elements (e.g.> 
if/then/else) common to most high-level lan- 
guages, and a few straightforward conventions 
that are generally clear in context. For 
example, a call is frequently shown in the 
form: "Call PROCEDURE(X, Y, Z)"3 this 
results in calling PROCEDURE and passing it 
the arguments X, Y, and Z. 


Abbreviations commonly used in the text are 
listed at the back of the book on foldout 
pages (Appendix T) for easy reference. 
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CHAPTER 2. OVERVIEW OF THE LU 
INTRODUCTION 


CONCEPTS 


This chapter is an overview of logical unit 
type 6.2 (hereafter referred to simply as 
U). The LU provides application programs 


AND TERMS 


DISTRIBUTED TRANSACTION PROCESSING 


Distributed transaction processing involves 
two or more programs, usually at different 
systems, cooperating to carry out some proc- 


essing function. This involves = program 
intercommunication to share each other's 
local resources such as processor cycles, 


data bases, work queues, or human interfaces 
such as keyboards and displays. 


The LU supports distributed transaction proc- 
essing by serving as the port between the 
programs and the Path Control network. It 
allows a transaction program (TP) to invoke 
remote programs and to exchange data with 
them. 


All communication provided by the LU is 
program-to-program. Any end user that is not 
a program is represented to the LU by a pro- 
gram. For example, fixed-function terminals 
and their devices (e.g., keyboards and dis- 
plays) present themselves as fixed programs 
(e.g.» microcode) that use the same LU func- 
tions as user-written application programs. 
Human users at workstations do not interact 
directly with the LU but rather with local 
workstation programming support which in turn 
interacts with the LU. 


This program-to-program communication accom- 
modates a variety of distributed processing 
connections, including peripheral node to 
subarea node, subarea node to subarea node, 
and peripheral node to peripheral node. For 
example, an application program at an 
outlying site (a terminal or a distributed 
processor) might communicate with a data-base 
management system at a central processor to 
maintain consistency between regional and 
central records. For another example, sys-~- 
tems programs in workstations might exchange 
files and documents with each other. 


Figure 2-1 on page 2-2 illustrates the role 
of the LU in relation to an SNA network. The 
LU connects transaction programs to the path 
control network. The LUs activate sessions 


with support functions for distributed trans- 
action processing. 


between themselves. The component of a ses- 
Sion in each LU is called a half-session. 
Two or more sessions between the same pair of 
LUs are called parallel sessions. Multiple 
sessions can concurrently use the same phys- 
ical resources connecting the LUs. 


The logical connection between a pair of 
transaction programs 1s called a 
conversation. A transaction program initi- 
ates a conversation with its partner with the 
assistance of the LUs. While a conversation 
is active, it has exclusive use of a session, 
but successive conversations may use the same 
session. 


An LU may run many transaction programs suc- 
cessively, concurrently, or both. Each 
transaction program may be cormected to one 
or more other transaction programs by conver- 
sations. Multiple conversations between di f- 
ferent pairs of transaction programs can be 
active concurrently, with each conversation 
using a distinct session. 


Conversations connect TPs in pairs, but any 
TPs directly or indirectly connected to each 
other by conversations are participating in 
the same distributed transaction. For exan- 
ple, if TP A and TP B are connected by a con- 
versation, and, concurrently, TP B and TP C 
are connected by a conversation, then TPs Ay, 
B, and C all are participating in the same 
distributed transaction. 


TRANSACTION PROGRAMS 


The direct user of the LU is an application 
transaction program (application TP). Appli- 
cation TPs are provided by the end user to 
carry out functions of distributed applica- 
tions. 


A transaction program is distinguished from 
programs in general by two characteristics: 
the way it is invoked, and the communication 
functions it initiates. 
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Attach to simulate invocation by another 
transaction program. It does this’ in 
response to some external stimulus, e.g., 
operator action. )} 


A transaction program uses the LU to communi- 
cate with other transaction programs by issu- 
ing transaction program verbs (which are 
described in the publication SNA Transaction 
Programmer's Reference Manual for LU Type 
6.2). (In some cases, internal LU components 
also issue transaction program verbs on 
behalf of transaction programs. ) 


Besides application transaction programs, 
distributed transactions can include trans- 
action programs provided by the LU itself, 
called service transaction proqrams (service 
TPs). These are SNA-defined transaction pro- 
grams within the LU that provide utility 
services to application transaction programs 
or that manage the LUs. They are attached by 
other transaction programs and they issue 
transaction program verbs to commmicate with 
other transaction programs. For example, the 
LU includes service transaction programs for 
distributed operator control of the LU, by 
which control operators can determine the 
rmmber of parallel sessions they will share, 
and for syne point resynchronization, which 
assists distributed transaction recovery fol- 
lowing transaction failure in certain circum- 
stances. Other service TPs provide document 
interchange services (using Document Inter- 
change Architecture [DIA]), which allow 
processors and workstations to synchronously 
exchange files and documents. Furthermore, 
SNA Distribution Services (SNADS) service TPs 
provide asynchronous distribution of files 
and documents. 


Different execution instances of the same 
transaction program could perform parts of 
the same distributed transaction at different 
LUs or parts of several different trans- 
actions at the same LU. 


CONTROL OPERATOR 


The LU control operator describes and con- 
trols the availability of certain resources 
(see "Resources"); for example, 1t describes 
network resources accessed by the local LU 
and it controls the number of sessions 
between the LU and its partners. 


The LU control cperator is represented to the 
LU by a control-operator transaction program 
that interacts with the LU on behalf of, or 
in lieu of, a human operator. The relation- 
ship between the control-operator transaction 
program and the LU control operator = is 
implementation-defined. 


The control-operator transaction program 
invokes operator functions by issuing 
control-operator verbs. These verbs are 
issued by the control-operator transaction 
program to convey operator requests to the 
internal components of the LU. 
Control-operator verbs are described in SNA 


Transaction Programmer's Reference Manual for 
LU Type 6.2. 


RESOURCES 


The LU provides several kinds of resources to 
support distributed transactions. 


Conversations connect transaction programs 
and are used by the transaction programs to 
transfer messages. A conversation is acti- 
vated when one transaction program attaches 
another. 


Associated with each end of a conversation 
are protocol states that each LU maintains in 
order to coordinate interaction between the 
two TPs. These indicate (for example) which 
TP is sender and which 1s receiver at a given 
time. 


The LU provides two types of conversations. 


Mapped conversations allow the TPs to 
exchange arbitrary data records in any format 
set by the programmers. 


Basic conversations allow TPs to exchange 
records containing a tato-byte Length prefix. 


Application transaction programs typically 
use mapped conversations, and service trans- 
action programs typically use only basic con- 
versations; however, either conversation type 
might be used by either program type. 


Sessions provide relatively long-lived con- 
nections between LUs; a session can be used 
by a succession of conversations. Sessions 
are activated by LU pairs as a result of 
operator commands and  transaction-program 
requests for conversations. They are not 
explicitly visible to transaction programs; 
for example, ai transaction program cannot 
explicitly request use of a particular ses- 
Sion. 


A mode is a set of characteristics that may 
be associated with a session. These charac- 
teristics typically correspond to different 
requirements for cost: performance, and so 
forth. Modes are defined by the control 
operator as a selection of 
path-control-network facilities and LU 
session-processing parameters. 


One characteristic of mode is class of serv- 
ice. The path control network can offer dif- 
ferent classes of service that correspond to 
particular physical links and routes and par- 
ticular transport characteristics such as 
path security, transmission priority, and 
bandwidth. 


Other characteristics of mode include 
operator-selected processing parameters such 
as message-unit sizes and the number of mes- 
sage units sent between acknonmledgments (pac- 
ing window sizes). 


Each mode characterizes a group of sessions 
with a particular partner LU; multiple modes 
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may exist for the same partner LU. Modes 
associated with different partner LUs are 


considered distinct, even if they represent 


similar sets of characteristics. 


A combination of partner LU and wmode is 
called an (LU,mode) pair. 


LU-accessed network resources constitute the 
relatively static environment that the LU or 
its containing node establishes as a result 
of installation definition. The. principal 
components of this environment are the. LU 
itself, the control points that serve the LU, 
the transaction programs that the LU can run, 
the potential partner LUs (remote LUs) with 
which the LU can communicate, and the modes 
of service available between the LUs. 


Local resources are resources whose principal 
functions and operations are not defined by 
SNA, but which LU components use or interact 
with for sore functions. These include local 
files, data bases, recovery and acccunting 
logs, queues, and terminal components. For 
example, LU components interact with local 
data-base managers to coordinate distributed 
error recovery of data-base updates. Also, 
SNA distribution services uses queues to 
exchange messages between application trans- 
action programs that provide document routing 
and distribution. 


Protected resources are local resources, such 
as data bases, whose state changes are logged 
so that all resources changed by a trans- 
action can be restored to a consistent state 
in the event of a transaction failure. The 
LU interacts with protected resources to pro- 
vide the sync point function (see "Sync Point 
Function" on page 2-39) for distributed error 
recovery. 


PROTOCOL BOUNDARIES 


In order to accommodate LU implementations on 
different processors and transaction programs 
written in different programming languages, 
SNA defines the LU's interface to application 
transaction programs in generic terms only. 


This specification is called the transaction 


program protocol boundary. It consists of 
the set of LU functions that a TP may 
request, and the possible parameter values 
that may be supplied or returned for these 
functions. 


SNA does not define a particular syntax or 


format for representing these functions and 
parameter values. Nevertheless, for purposes 
of discussion in SNA publications, the func- 
tions and parameters are represented gener- 
ically by transaction program verbs; these 
are described in SNA Transaction Programmer's 
Reference Manual for LU Iype 6.2. 


Each LU implementation has one or more pro- 
gramming environments that provide these 
functions. Each such environment is called 
an applications programming interface (API). 


The .U actually presents a partitioned proto- 
col boundary to the transaction program; for 
example, there are separate subsets of the 
verbs for mapped conversations, for basic 
conversations, and for SNADS. When a hierar- 
chical relationship exists between these sub- 
sets, e.g., when verbs from one set cause 
internal issuances of verbs from another set, 
this partition introduces sublayers within 
the LU. 


A protocol boundary can be interpreted from 
two points of view. 


From one point of view, a protocol boundary 
is a boundary between tuo layers or sublayers 
of the node. For example, TPs exchange data 
with LUs across the TP-LU protocol bourdary, 
and LUs exchange data with the path control 
network across the LU-path-control protocol 
boundary. From this viewpoint, the rules of 
exchange are called Jayer pretocols. 

But from another point of view, a protocol 
boundary its a boundary between two peer com- 
ponents of the same layer. In other words, 
the transaction program protocol boundary may 
be thought of as a direct boundary betreen 
one TP and another, and similarly, the path 
control protocol boundary may be regarded as 
a direct boundary between LUs. From this 
Viewpoint, the rules of exchange are called 
peer protocols. 


Figure 2-2 on page 2-5 shows the principal 
protocol boundaries between the LU and 
external components. The figure illustrates 
how the protocol boundaries divide the LU 
into layers and sublayers, and hew the con- 
ceptual flows between peer components are 
accomplished by interlayer exchanges. In 
this example, the application TP has a mapped 
conversation with another application TP and 
a basic conversation with a service TP. The 
figure illustrates that the conceptual infor- 
mation flow between peer components at each 
layer is reduced to conceptual information 
flow at the next lower layer by actual infor- 
mation flow between layers and information 
transformation within layers. For example, 
the conceptual mapped conversation connection 
is reduced to a basic conversation; each bas- 
ic conversation is reduced to a session; and 
finally, the sessions are reduced to con- 
nections in the path control network (which 
itself performs further layer transformations 
that are not shown). 


NAMES 


The LU allows transaction programs to refer 
to its resources, such as other TPs and LUs 
and shared communication facilities, by 
installation-selected names. Thus, the pro- 
grams need not be concerned with implementa- 
tion and configuration details such as the 
actual network addresses or transport charac- 
teristics. For example, when one transaction 
program invokes another, the invoking TP 
identifies the partner TP by a transaction 
program name, it identifies the partner LU by 
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an LU name, and it identifies) the desired set 
of session characteristics by a mode name. 


Names are character strings that the instal- 
lation associates with particular resources. 
They are specified by the control operator 
(on behalf of the installation management) 
subject to the SNA-imposed constraints, e.g.> 
character set and = Ilength restrictions, 
described tn "Appendix H. FM Header and LU 
Services Commands". (Within an LU implemen- 
tation, the local resource names may differ 
from those that conform to SNA; for example, 
a program directory might use names of a dif- 
ferent length or character set. In this 
case, the implementation always translates 
between its internal names and =the 
SNA-conforming names that are used by trans- 
action programs or that are transmitted out- 
side the LU.) 


The name of a particular resource is Known 
within a particular environment... Within this 
environment, the name of each entity of a 
particular class 15 wumique, but the same 
entity might have different names in differ- 

ent environments. For example, each LU 
allows local aliases for remote resource 
names, so that local transaction programs can 
be made insensitive to name changes elsemhere 
in the network. Of course, the control oper- 
ator mus t change the LU's relevant 
name-translation tables whenever the remote 
names are changed. 


Roles 


Hereafter, the following terms are used to 
distinguish the roles of individual TPs and 
LUs of a pair. With respect to location, the 
term local means residing at the LU from 
whose perspective an activity is described; 
the term remote means residing at that LU's 
actual or potential session partner. With 
respect to a conversation, the source TP (or 
its LU) ts the initiator of a conversation 
with the target TP (or its LU). 


Transaction Program References 


A source TP selects a target transaction pro- 
gram by its transaction program name (TPN) as 
defined at the source LU. In the simplest 
case, this is also the name of the TP as 
defined at the target LU. Optionally, honev- 
er, the source LU can allow the two names to 
be different, in which case it converts the 
TP-supplied name into the TPN recognized at 
the target LU. 


A TPN alone does not uniquely identify a 
transaction program instance. The target LU 
creates a new transaction program instance 
for each Attach it receives. 


Chapter 2. Overview of the LU 2-5 


2-6 


LU References 


Each LU provides a set of LU names by which 
its TPs may refer to remote LUs: these names 
are called local LU names (a local LU name 
is a local alias of a remote LU's name, not 
the local LU's own name). Local LU names are 
unique within each local LU, but not neces- 
sarily outside an LU. 


The path control network routes information 
to an LU by a network address rather than by 
aname. The correspondence between names and 
addresses 15 maintained at the control point, 
which is another NAU that assists the LU dur- 
ing session initiation. 


The control point identifies each LU by its 
fully qualified LU name (also called 
network-qualified LU name). It consists of a 
network ID followed by a network LU name. 
The network ID is unique throughout a set of 
interconnected SNA networks; the network LU 
name is unique within a particular SNA net- 
work, which may contain multiple domains (for 
more information on domains; see "Chapter I. 
Introduction"). 


The control point uses the fully qualified LU 
name of the intended partner LU to determine 
the corresponding network addresses used for 
routing within the path control netvork. The 
LUs themselves use their fully qualified LU 
names for certain purposes; for example, LUs 
resolve some race conditions by exchanging 
and comparing their fully qualified LU names. 


An LU may provide another set of names by 
which it refers to remote LUs when issuing 
session-initiation requests to its control 
point: these names are called uninterpreted 
LU names. Each uninterpreted LU name is 
unique within a particular initiating LU, and 
is known to that LU's control point but is 
not known elsewhere in the network. 


The LU name is converted into the netpork 
address tn stages. If the LU uses an unin- 
terpreted LU name to identify its partner, 
the control-point translates this into a ful- 
ly qualified LU name; otherwise, the LU sup- 
plies the fully qualified LU name to the 
control point directly. Then, the control 
point provides the netvork address for that 
fully qualified LU name. 


Mode Names 


A source TP cannot select a particular ses- 
sion for a conversation, but it can specify 
that the session selected have a particular 
set of characteristics, or mode. It does 
this by specifying a corresponding mode name. 


Mode names are unique relative to a partic- 
ular partner LU. Mode names for different 
partner LUs are independent: the same mode 
name can correspond to different sets of ses- 
sion characteristics for different partner 
LUs. 


s 


Internal Identifiers 


The LU assigns internal identifiers to con- 
versations and sessions once they are acti- 
vated. These are called resource IDs and 
half-session JDs, respectively. TPs or the 
control operator use these identifiers for 
subsequent references to these entities. 
These identifiers are generated by the LU and 
passed back to the transaction program or to 
the control operator in the form required for 
subsequent verbs; the transaction program or 
operator need not interpret these identifi- 
ers. 3 


CONVERSATION CHARACTERISTICS 
Send/Receive Protocol 


The LU normally allows TPs to exchange data 
in only one direction at a time, i.e., one TP 
sends and the other receives until the send- 
ing TP surrenders the right to send. This is 
called half-duplex flip-flop protocol. The 
LUs coordinate and enforce the send/receive 
state at each end of the conversation. LUs 
do allow some exceptions to strict alter- 
nation of send and receive: the receiving 
TP, at any time, can send an error indi- 
cation, putting itself in send state; it can 
send the partner an attention indication, 
@.g., to request the right to send; and it 
can abnormally terminate the conversation. 


Sender/Receiver Concurrency 


Different applications require different 
degrees of concurrency between sender and 
receiver. For example: 


¢ On-line inquiry applications might 
require real-time interaction. 


@ Status-reporting applications might 
require immediate transmission but no 
response. | 


® Document distribution applications might 
allow sending and receiving at the send- 
er's and receiver's convenience, respec- 
tively, which might be separated by 
arbitrary periods of time. 


For the first two cases, the LUs use direct 
conversations between the TPs. 


For the real-time interactive case, the LU 
keeps the TP-TP connection active until the 
transaction is completed; both the source and 
target TPs are concurrently active. This is 
called synchronous transfer. 


The LU treats the immediate-transmission> 
No-response case as a special case of syn- 
chronous communication, using a one-way con- 
versation. The source LU allocates 
(initiates) a conversation as in the first 
case, sends the data, and deallocates (re- 
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leases) the conversation. When the message 
reaches the target LU, it initiates the tar- 
get TP, which receives the data and likewise 
deallocates the conversation. But since the 
source TP is expecting no reply, it might 
have terminated while the data is still in 
transit through the path control network, 
before the target TP is initiated. Thus, the 
source and target TPs are not necessarily 
active at the same time. 


For the third case, the LU provides SNA Dis- 
tribution Services (SNADS). In this case, 
the sender, called the origin TP, and the 
ultimate receiver, called the destination TP,» 
are typically not active at the same time. 
Therefore, the data is stored at one or more 
locations en route betmeen periods of active 
transmission. This mode of communication 15 
called asynchronous transfer. 


In SNADS;, the origin application TP sends a 
message unit, ultimately intended for the 
destination TP, to a local service TP. The 
service TP at the origin stores the data in 
local permanent storage. When the appropri- 
ate time for sending the data arrives, e.g.» 
when lower-cost transmission facilities 
become available or after compensating for 
time-zone differences, a service TP at the 
origin allocates a conversation to a service 
TP at the destination and sends the data. 
The receiving service TP at the destination 
LU stores the data in local permanent storage 
for later retrieval. Finally, an application 
TP at the destination retrieves the stored 
message. 


SNADS also allows multiple intermediate serv- 
ice TPs between origin and destination. The 
origin service TP can allocate a conversation 
to an intermediate service TP, which would 
receive the data, store it, and later forward 
it to another intermediate service TP or to 
the ultimate destination service TP. 


Each SNADS service TP can also duplicate the 
data and send it to multiple destinations or 
application programs. 


Mappin 


Two communicating TPs might process the same 
information using different internal data 
formats (presentation spaces) e.g., differ- 
ently organized data structures or different 
sets of individual structures and variables. 
To assist the TPs in interpreting data in 
formats suited to their internal processing 
algorithms while providing a mutually under- 
stood format for the data transmitted over 
the conversation, some LUs provide = an 
optional function of mapped conversations, 
called mapping. (Mapping concepts are dis-~ 
cussed in "Mapping Function" on page 2-39). 


SESSION ALLOCATION 


A principal function of the LU is to provide 
sessions between LUs for use by conversations 


between TPs. 


Session Multiplicity 


Only one transaction-program pair at a time 
can use a particular session. In order to 
allow multiple concurrent transactions, e.g.» 
for a multiprogrammed processor or a 
multiple-user workstation, some LUs, called 
parallel-session LUs, allow two or more ses- 
Sions at the same time, even with the same 
partner LU. Any session between a pair of 
LUs that both provide parallel sessions is 
called a parallel session, even if only one 
such session is currently active. 


Some LUs, called single-session LUs, can have 
only one active LU-LU session at a time (but 
can have successive sessions with different 
partner LUs). Any session. involving a 
single-session LU is called a single session, 
whether the other partner is a single-session 
LU or a parallel-session LU. 


Thus, all sessions between a pair of LUs are 
of the same type: single or parallel. Some 
LU protocols used on single sessions are dif- 
ferent from those used on parallel sessions, 
but these differences are indistinguishable 
to transaction programs. 


An LU that does not support parallel sessions 
can have only one active LU-LU session at a 
time. A parallel-session LU can have, con- 
currently, one or more parallel-sessions with 
each of one or more parallel-session LUs, and 
one single session with each of one or more 
Single-session LUs. (No middle capability 
[multiple-session LU] exists, i.e., any LU 
that supports multiple concurrent single ses- 
sions also supports parallel sessions. ) 


Session Pool 


To avoid repeating session-activation proc- 
essing for each conversation between the same 
pair of LUs, the LU allows successive conver- 
sations to use the same session. 


When the LU activates a session or when a 
session previously in use by a conversation 
becomes free, the LU places the session in a 
session pool. When a transaction program 
initiates a new conversation, the LU allo- 
cates a session from this pool, if one is 
available. 


Session Selection 


Transaction programs do not select particular 
sessions, but specify only that the conversa- 
tion be allocated a session with a particular 
partner LU and with a particular mode name. 
The LU partitions the session pool by partner 
LU and mode name; the LU allocates a session 
from only those sessions for the requested 
(LU,»mode) pair. 
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Session Contention Polarity 


Another session-selection criterion concerns 
the relative priority of the LU for use of 
the session. The LUs at each end of a ses- 
sion could both try to start a conversation 
at the same time. To resolve this con- 
tention, the LU operator specifies, for each 
session, which LU's TP will be allowed to use 
the session in such a case; this is called 
the session contention polarity of the ses- 
sion. From the viewpoint of the local LU, a 
session for which that LU its designated to 
win an allocation race is called a 
contention-winner session (or first-speaker 
session). A session that the local LU will 
sur“ender to the partner is called a 


contention-loser session (or the bidder ses- 


sion--so called because a contention-loser LU 
will bid, i.e., request permission of the 
contention-winner LU to use the session). 


Session Limits 


The number of sessions in the session pool is 
constrained by operator-specified criteria, 
including several limits on the number of 
active sessions. 


The total LU-LU session limit is the maximum 
number of sessions that can be active at one 
time at the LU. 


The (LU,mode) session limit is the maximum 
number of LU-LU sessions that can be active 
at one time for that particular (LU,mode) 
pair. 


The automatic activation limit for a partic- 
ular (LU,mode) pair specifies the maximum 
number of LU-LU sessions that the LU will 
activate independently of requests for con- 
versations. Automatically activated sessions 
constitute the initial session pool (addi- 
tional sessions, within the other limits, are 
added to the pool on demand from conversation 
requests). 


The local-LU minimum contention-wimmer limit 
for a particular (LU,mode) pair determines 
the minimum share of the total number of ses-~- 
sions for that (LU,mode) for which the local 
LU can be contention winner. Similarly, the 
partner-LU minimum contention-winner limit 
determines the minimum share of those ses- 
sions for which the partner LU can be con- 
tention winner. 


Session Limits are discussed in more detail 
in “Chapter 5.4%. Presentation Serv- 
ices--Control-Operator Verbs". 


STARTING AND ENDING SESSIONS 
Phases 


Starting and ending sessions involves four 
phases of activity, although some phases are 
omitted in some circumstances. 


Session-limit Initialization and reset con- 
sists of issuing control-operator verbs 
(e.g.» INITIALIZE _SESSION_LIMIT, 
RESET_SESSION_LIMIT) to specify the number of 
sessions the LU can have with a given part- 
ner, and to specify conditions for their 
activation and deactivation. 


Session initiation and termination consists 
of control-point activity, such as supplying 
the network addresses corresponding to LU 
names, that mediates requests for session 
activation and deactivation. 


Session shutdown consists of the LU activity 
to terminate conversation activity on a ses- 
sion prior to deactivating the session. ? 


Session activation and deactivation consists 
of creating or destroying the end-to-end log- 
ical connection between the LUs.? 


SESSION USAGE CHARACTERISTICS 


Session Activation Polarity 


An LU activates a session with its partner by 
sending a message unit called BIND. The LU 
that activates a session (sends BIND) is 
called the primary LU; the LU that receives 
BIND is called the secondary LU. These terms 
are relative to a particular session: the 
same LU can be primary LU for one session and 
secondary LU for another. 


The primary LU always has first use of the 
session, 1.@€.»5 it can initiate the first con- 
versation on the session, regardless of the 
session contention polarity. (When the first 
conversation completes, the principal right 
to initiate conversations reverts to the 
contention-winner LU.) 


Session-Level Pacing 


To prevent an LU from sending data faster 


than the receiving LU can process it (e.g.> 


empty its receive buffers), the two LUs 
observe a sesston-level pacing protocol. At 
the time a session is activated, the LUs 
exchange the number (the pacing window size) 
and size (the maximum RU size) of the message 
units they can accept at one time. The send- 


Session initiation and termination protocols use session services RUs, e.g., INIT SELF, 


1 
CINIT. 
: Session shutdown protocols use data flow control RUs,» e.g., BIS. 


Session activation and deactivation protocols use session control RUs, e.g.» BIND, UNBIND. 
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ing LU will send no more message units than 
the receiver will accept (a pacing window) 
until the recetver sends an acknowledgment 
(pacing response) indicating that it can 
receive another pacing window. 


Profiles 


Session traffic is characterized by a partic~ 
ular set of SNA-defined formats and proto- 
cols, identified by a function management 
(FM) profile and a transmission services (TS) 


profile (see “Appendix F. Profiles"). The 
profile used depends on the Kind of session 
and the kind of node: 


e On an LU-LU session, all LUs use FM pro- 
file 19 and TS profile 7. 


e On a CP-LU session, an LU in a subarea 
node uses FM profile 6 and TS profile 1. 


® Ona CP-LU session, an LU in a peripheral 
node uses FM profile 0 and TS profile 1. 
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The LU provides three functions to assist the 
installation in providing security: partner 
LU verification, partner end-user verifica- 
tion, and session cryptography. Partner-LuU 
verification is a session-level security pro- 
tocol; it involves protocols at the time the 
session is activated. Partner end-user ver- 
ification 15 a conversation-level security 
protocol, taking place at the time a conver- 
sation is started. Session cryptography is 
another session-level protocol, the parame- 
ters for which are exchanged at session acti- 
vation. 


Partner-LU verification is done by a 
three-flow exchange between the two LUs, with 
each LU using an LU-LU password and the Data 
Encryption Standard (DES) algorithm. This 
exchange 1s called LU-LU verification. LU-LU 
passwords (see "Appendix H. FM Header and LU 
Services Commands") are established by imple- 
mentation and installation-defined methods 
outside of SNA. LU-LU passwords are on a 
partner-LU basis: one LU-LU password is 
established between each LU pair. This pass- 
word is used for all sessions between the LU 
pair. It is recommended that each LU pair 
have a unique password; however, it is not an 
architectural requirement. 


Figure 2-3 shows the LU-LU verification pro- 
tocol exchanges. In the following dis- 


correspond to the numbers in that figure. 


During session activation, random data (RD1) 
is sent in BIND from the primary LU to the 
secondary LU (1). The secondary LU enciphers 
this random data using the LU-LU password and 
the random data as input to the DES algo- 
rithm. The secondary LU returns (2) the now 
enciphered random data (PWIRD1]) to the pri- 
mary LU along with its own randomly generated 
data (RD2) in RSP(BIND). The primary LU com- 
pares the received enciphered random data 
with its own copy of the random data that it 
enciphered using its LU-LU password and the 
DES algorithm. If the two versions of the 
enciphered random data do not compare equally 


(3a), LU-LU verification fails, session acti- 
vation fails, and a security violation is 
logged. If the two versions of the enci- 


phered random data compare equally (3b), the 
primary LU has verified the identity of the 
secondary LU and LU-LU verification contin- 
ues. 


Using the LU-LU password atid the DES algo- 
rithm, the primary LU enciphers the random 
data received from the secondary LU. The 
primary LU returns this enciphered random 
data (PWIRD2])}) in a Security FM header 
(FMH-12) to the secondary LU (3b). The sec- 
ondary LU compares this enciphered random 
data with its own version of the enciphered 
random data. If the two versions of the 
enciphered random data do not compare equally 
(4a), LU-LU verification fails, the session 
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is terminated, and a security violation is 
legged. If the two versions of the enci- 
phered random data compare equally (4b), the 
secondary LU has verified the identity of the 
primary LU, and LU-LU verification is com- 
plete. 


When the transmission links and LUs that make 
up the network are physically secure (as 
determined by the installation management), 
LU-LU verification may be omitted. Under 
this circumstance, LU-LU verification mould 
not take place, yet the session would still 
be considered secure; therefore, access to 
secure resources would still be permitted 
following conversation-level security proto- 
cols (see below). Permission to use 
conversation-level security to gain access to 
secure resources 1s installation defined and 
communicated to the partner LU during session 
activation in the BIND/RSP(BIND) exchange. 


When the network is not considered secure, 
LU-LU verification should be omitted, and 
access to secure resources via 
conversation-level security should not be 
permitted. Denial of permission to use 
conversation-level security is installation 
defined; an indication of this denial is com- 
municated to the sender of the request during 


session activation in the  BIND/RSP( BIND) 
exchange. 
End-user verification (conversation-level 


security) is used to confirm the identity of 
the partner end user (e.g., transaction pro- 
gram). When a TP requests access to another 
TP, 1t must supply adequate security informa- 
tion in the request to satisfy the security 
requirements of the requested TP, or the 
request will be rejected. This could include 
a user ID and password (see access security 
information subfields in “Appendix H. FM 
Header and LU Services Commands") supplied by 
the end user that initiated the request. 
When a user ID and password are supplied on 
the request, they are verified by the LU that 
receives them. If the end user has not sup- 
plied the correct user ID and password combi- 
nation, the request is rejected. 


An optional additional criterion for access 
to a specific TP is permitted. This criteri- 
on would be a check of an authorization List 
associated with the target transaction pro- 
gram. The keys to search the authorization 
list would be combinations of the user ID and 
an optional profile supplied on the request. 
The authorization list could be made up of 
combinations of user ID and profile. After 
the user ID is verified by the LU, the 
authorization list may be searched for access 
rights to the specific transaction program 
named in the request. If the additional cri- 
terion is not met, the request is rejected. 


An intermediate transaction program (one 
started by another TP) that requires 
conversation-level security may need = to 
access an additional TP that requires 


conversation-level security. In this case, 
an Already Verified indicator is set in the 
additional request; the user ID and optional 
profile in the first request, which initiated 


the intermediate transaction program, 
supplied in the second request. 
reasons, the password that initiates the 
intermediate TP is never saved, kwt the user 
ID and optional profile that initiated the 
intermediate TP are saved. The Already Veri- 
fied indicator can be used only if the sender 
of the indicator is. trusted by the receiver 
of the indicator to have performed the proper 
verification of the user ID and rassword that 
initiated the sender. This level of trust is 
installation defined at the receiver of the 
indicator and communicated to the sender of 
the indicator during session activation in 
the BIND/RSP( BIND) exchange. 


are 
For security 


To help prevent data from being interpreted 
or modified during transit, the LU provides 
session cryptography, whereby all user data 
is enciphered at the source LU and deciphered 
at the target LU. The encryption algorithm 
uses a cryptographic key,» supplied by the 
control point, and a session seed, generated 
by one of the LUs when the session is acti- 
vated. (See "Chapter 6.2. Transmission Con- 
trol" for aoe full discussion of session 
cryptography. ) 


ERROR HANDLING 


Kinds of Errors 


Pr RCD 


Errors affecting transaction processing are 
classified as follows: 


Application Errors: These are errors related 
to the application data and processing» e.g.» 
user input error or data-base record missing. 
Detection and recovery are the responsibility 
of the transaction programs. 


Local Resource Failure: These are failures 
in non-SNA resources, e.g., a disk read 
error. If the resources are not protected 
resources, recovery is the responsibility of 
the transaction program or of the non-SNA 
support for the failing resource, e.g.; a 
disk subsystem. If the resource is a pro- 
tected resource, the TPs can use the LU syne 
point function (see "Syne Point Function" on 
page 2-39) to assist in recovery in conjunc- 
tion with non-SNA support. 


Recoverable System Errors: These are errors 
or exceptional conditions, e.g.» races 
resulting from contention for use of a ses- 
sion, for which an SNA-defined recovery algo- 
rithm exists. The LU performs the recovery 
algorithm; the transaction programs == are 
normally not aware of these errors, except as 
they affect timing. 


Program Failures: These are errors” that 
cause abnormal termination of a transaction 
program. The LU recovers from such errors by 
deallocating any active conversations for the 
TP that were not deallocated by the failed 
transaction program, thus freeing the ses- 
sions for use by other transaction programs. 
Any further recovery depends on transaction 
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program logic and = implementation-defined 
capabilities such as error exits. 


Session Failure: These are failures caused 
by unrecoverable failure of the 
half-sessions, e.g.» invalid session proto- 
cols received, or by failure of the underly- 
ing network components, e.g.» the links. 
This case is reported to the LUs through ses- 
Sion outage notification (SON). 


If a conversation is active on the session at 
the time of failure, the failure is mani- 
fested to the transaction program as a con- 
versation failure (see below); otherwise, 
these errors do not affect transaction pro- 
grams. LUs report the conversation failure 
to the affected transaction programs. 


Conversation Failures: These are failures 
caused by unrecoverable failure of the under- 
lying session. The resulting conversation 
failure is reported to each transaction pro- 
gram by ai return code on the next verb 
issued. The same session and conversation 
cannot be recovered, but the LU can activate 
another session. 


The operator or the transaction programs have 
the responsibility to recover the trans- 
action. To recover from an interruption in 
transaction processing, for example, the 
source transaction program can allocate a new 
conversation, using another session, to a new 
instance of the target transaction program or 
to another transaction program. 


LU Failure: This is a failure of an LU from 
such causes as malfunction of the implement- 
ing hardware or software. In many cases, 
such a failure appears to remote 
(non-failing) LUs as a session failure, and 
they recover as they would from any other 
session failure. In some cases, recovery is 
performed by the sync point function. 


Program Error Recovery Support Functions 


The LU assists TP recovery from application 
errors and local resource failures by sup- 
porting the protocols discussed below to 
exchange error information and to immediately 
end messages or conversations. 


Confirmation: This function (Ce.g., CONFIRM 
verb) allows a TP to solicit positive or neg- 
ative acknowledgment of a message unit from 
the partner TP. The interpretation of this 
positive or negative acknowledgment (CON- 
FIRMED or SEND_ERROR verbs, respectively) is 
program dependant: for one application, con- 
firmation might mean only that the data was 
received; for another, it might mean data was 
safely stored on disk; for a third, it might 


mean that the data represents a valid account 


record update; and so forth. 


Program Error Indication: This function 
(SEND_ERROR verb) allows a TP to inform the 


partner TP of a program-detected error; this 


includes sending negative acknowledgment to a 
confirmation request. 


This function also causes program-to-program 
transfer of the current message unit to 
cease. If a TP detects an error ohile 
receiving, issuing the SEND_ERROR verb 
directs the receiving LU to ignore any addi- 
tional data in transit (i.e., to the end of 
the conversation message--see "Conversation 
Message" on page 2-15); this is called purg- 
ing. Similarly, if a sending TP detects an 
error, issuing the SEND _ERROR verb informs 
the partner that the source TP has stopped 
sending. If the TP stops sending before 


reaching a predetermined application-program 


data boundary (i.e., the end of a logical 
record--see "Logical Record" on page 2-14), 
this is called truncation. 


Sync Point: Many transactions require con- 
sistent, regular updates of distributed 
resources such as distributed data bases. 
While a transaction is in progress, however, 
the resources at different {Us can enter 
mutually inconsistent interim states. If one 
of the transaction programs encounters an 
error, Some recovery action may be necessary 
to restore the resources to mutually consist- 
ent states. In order to verify or restore 
consistency among distributed resources, some 
LUs provide ai § distributed error-recovery 
function, called syne point. (Syne point 
concepts are discussed in "Sync Point Func- 
tion" on page 2-39.) 


Abnormal Conversation Deallecation: This 
function allows a TP to abnormally terminate 
a conversation. A TP might do this, for 
example, when an error is detected for which 
it has no recovery procedure and continuing 
the transaction would be meaningless. When 
this is received, the LU informs the TP that 
the conversation has been abnormally termi- 
nated. 


LU Error Recovery Functions--Abnormal Session 
Deactivation 


For some errors, the LU or operator initiates 
recovery. 7 


If an unrecoverable session-protocol error 
occurs, the LU abnormally deactivates the 
session. 


If the control operator detects an error, 
@.g.» an apparent deadlock or loop, it can 
force immediate abnormal deactivation of a 
session. 


Either of these cases are normally manifested 
to affected transaction programs as conversa- 
tion failure. 


BASE AND OPTIONAL FUNCTION SETS 


The LU functions and protocols are organized 
into subsets. The function sets consist of a 
base function set, which provides basic com- 
munication services common to all LU imple- 
mentations, and a small number of optional 
function sets, which may be used by tmplemen- 
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tations with more sophisticated additional 
requirements. These SNA-defined function 
sets are described in SNA Transaction Pro- 
grammer's Reference Manual for LU Type 6.2. 


All LU 6.2 implementations of a given func- 
tion set provide that function in a way that 
conforms to the protocol boundary. Further- 
more, an LU 6.2 implementation that provides 
one function in an option set provides all 
other functions tn that option set as well. 
Thus, all LU 6.2 implementations can communi- 
cate using the base set, and any two imple- 
mentations supporting functions in the same 
option set can communicate using that full 
option set. 


Two kinds of optional functions exist. Send 
options determine what formats and protocols 
will be sent but do not affect what can be 
received; all formats and protocols § sent 
using these options can be received by all 
LUs. Receive options determine what can be 
received as well as what can be sent. For 
receive options, the source LU and TP 
requirements are described in the BIND and 
the Attach; the receiving LU rejects the ses- 
sion or conversation if it, or the specified 
TP, does not support the required options. 


The principal base and optional functions are 
listed below. The complete sets are defined 
in SNA Transaction Programmer's Reference 
Manual for LU Type 6.2. 


Application Program Interface Implementations 


Qpen-API implementations support arbitrary 
user-written transaction programs, e.g.» a 


data-base management system running on a host 
processor. For these implementations, the 
API provides verbs and parameters for all of 
the base function set, and perhaps some 
optional function sets. 


Closed-API implementations do not support 
user-written programs but provide only a 
fixed, implementation-determined set of serv- 
ice transaction programs, e.g., a DIA service 
transaction program for ano office work- 
station. For these implementations, the API 
provides only the particular verbs and param- 
eters that the transaction program = set 
requires. 


MESSAGE UNITS AND THEIR TRANSFORMATIONS 


ARSPLATEREUTETE = EERE ENDO 


A message unit (MU) Is any bit-string that 
has an SNA-defined format and is transferred 
between SNA components or sublayers. 


Distributed transaction programs exchange MUs 
with each other by means of LUs. Transaction 
programs exchange application-oriented units 


of data, e.g., a customer record or a docu- 
ment, over a conversation. The LUs, in turn, 
exchange session-oriented MUs via the 


path-control network. But the content and 


Principal Base Functions 


Basic Conversations: All implementations 
provide receive support for all 


basic-conversation formats and protocols. 


Open-API implementations provide basic con- 
versation verbs, but not necessarily in all 
supported programming languages. For exam- 
ple, an tmplementation might support both 
basic- and mapped-conversation verbs in a 
systems-programming language such as Assem- 
bler, but provide only mapped-conversation 
verbs in high-level languages. 


Mapped Conversations: All open-API implemen- 
tations provide mapped conversations (prima- 
rily in high-level Languages). 


Principal Optional Functions 


Mapping: This 1s an optional function for 
mapped conversations (see "Mapping Function" 
on page 2-39). 


Syne Point: This is an optional function for 
basic and mapped conversations (see "Sync 
Point Function" on page 2-39). 


Program Initialization Parameters (PIP): 
This is the means of passing initial parame- 
ters or environment setup information to a 
target TP. 


Security: This is an optional function for 
verifying the identity of partner LUs and end 
users (see "Security" on page 2-10), and for 
for protection of data tn transit. 


Performance Options: Several optional func- 
tions exist to maximize performance for spe- 
cific transaction requirements. For example, 
an LU can optionally allow transaction pro- 
grams to eliminate or accelerate certain 
acknowledgments, or to perform processing 
concurrently with certain conversation func- 
tions. These are send options, so TPs writ- 
ten for implementations that support these 
options will operate correctly with partner 
TPs and LUs that do not support them. 


format of an MU most apprepriate for exchange 
between transaction programs is in general 
different from that most appropriate for 
transmission on a session. Whereas an appli- 
cation program typically uses a record size 
corresponding to logical groupings of the 
data, the LU typically uses MU sizes related 
to internal buffer sizes and efficient flow 
control. Furthermore, the LU may need to add 
encoded protocol information, such as confir- 
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mation requests or MU sequence numbers, to 


the program-supplied data. 


The LU transforms program-oriented MUs used 
by the TP into network-oriented MUs used by 
the path control network, and vice versa. 
(Throughout this section, message-unit tran- 
sformations are described from the sender's 
Side, 1.e., transaction program to LU to net- 
work; the process is inverted at the receiv- 
er.) 


The message-unit transformation takes place 
in stages. Each stage transforms some of the 
information from the higher stage into a 
SNA-defined bit string. Typically, a stage 
reblocks (regroups) the MUs from the previous 
stage into differently sized units and con- 
verts the protocol information into formatted 
headers (prefixes) to the reblocked data, 
thus creating new MUs. 


MAPPED-CONVERSATION MESSAGE UNITS 


A data record, at the mapped-conversation 
protocol boundary, is a collection of data 
values that correspond to the DATA parameter 
of a single mapped-conversation MC_SEND_DATA 
verb issuance. The format of a data record 
is completely arbitrary within the con- 
straints of the implementation and the trans- 
action program. For example, it need not 
even be a contiguous byte string, but might 
be a collection of variables and structures. 


A mapped-conversation record (MCR) is the 
elementary unit of information transferred 
between two TPs on a mapped conversation. A 
MCR contains the values of a data record 
represented as a string of contiguous bytes. 
It may be of arbitrary length. It contains 
no information for use by the LU; its 
internal format is significant only to the 
TP. The TP supplies needed protocol informa- 
tion, such as the mapped-conversation record 
length, in separate parameters of the verb, 
using representations appropriate to the pro- 
gramming language and processor being used. 


(A MCR consists of data from a single verb 
issuance by the sender, but it may be 
received in one or more parts, each with a 
Single verb issuance, depending on the 
receiving TP's receive buffer size). 


BASIC-CONVERSATION MESSAGE UNITS 


DS Variables 


Full connectivity among programs requires 
that all transaction programs interpret the 
records they transfer in the same way. To 
facilitate uniform interpretation of records 
among programs written for different process- 
ors, service transaction programs and some 
internal LU components » including 
mapped-conversation support, use the formats 
defined by general data stream architecture 
to represent records (see Appendix I). 


A general data stream (GDS) variable consists 
of a GDS header (LLID) followed by the data. 
The GDS header is a descriptive prefix con- 
taining a 2-byte length prefix (LL) that 
indicates the length of the variable, includ- 
ing prefix, and a format identifier called 
the GDS ID that indicates the GDS-defined 
format of the data. The Lls identify the 
boundaries of variable-length fields within a 
message unit of contiguous fields, and the 
GDS IDs identify the representation of the 
data. A GDS variable may be of arbitrary 
length. If the variable length exceeds the 
value that can be represented in the length 
prefix (225-1 = 32,767 bytes, including the 
prefix), the record consists of multiple seg- 
ments, each with its own length prefix. Only 
the first segment contains an ID field. The 
length prefix also contains a continuation 
bit that indicates whether the corresponding 
segment is the last (or only) segment in the 
GDS variable. 


All data transferred at the 
basic-conversation protocol boundary by serv- 
ice TPs and other internal LU components (but 
not necessarily data transferred by applica- 
tion transaction programs) is represented as 
GDS variables with SNA-defined formats (see 
"Appendix H. FM Header and LU Services Com- 
mands"). 


Logical Record 


A logical record is the elementary unit of 
information transferred between users of the 
basic-conversation protocol boundary. A log- 
ical record consists of a 2-byte length pre- 
fix (LL) followed by data. Its maximum 
length is 32,767 bytes, including the prefix. 


The LL prefix of a logical record has the 
same format as the LL field in a GDS variable 
segment; thus, a GDS variable segment is also 
a logical record., The basic-conversation 
protocol boundary requires only the LL pre- 
fix, not a full GDS LLID. Thus, logical 
records generated by application TPs need not 
use ID fields; if they do, the application 
assigns and interprets the ID fields; the 
basic-conversation support of the LU treats 
everything following the LL prefix of the 
logical record as user data. 


The logical record is the elementary unit for 


which the LU detects or reports truncation. 


Buffer Record 


It might be inconvenient for a transaction 
program to issue a single send or receive 
verb for each logical record. For example, 
the sender or the receiver might have limited 
buffer space or might not Know ahead of time 
the maximum length of the records being sent. 
Or, the transaction program might prefer to 
send a group of small, related records with a 
single verb issuance. So, the unit of data 
that a program sends or receives with a sin- 
gle basic-conversation verb = is of 
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program-determined length. This unit § is 


called a buffer record. 


No SNA-defined limit exists on the length of 
a buffer record; for example, it could exceed 
32,767 bytes. The buffer-record length can 
be different for each verb issuance. 


No correspondence is necessary between the 
lengths or boundaries of logical records and 
those of buffer records, or between send 
buffer records and recetve buffer records. 
Nevertheless, a receiving program may 
optionally specify that the LU begin a new 
receive buffer record for each new logical 
record received. The relationship between 
logical records and buffer records is illus- 
trated in Figure 2-6 on page 2-19. 


CONVERSATION MESSAGE-UNIT SEQUENCES 


Certain sequences of message units are rele- 
vant to conversation protocols. 


Conversation Message 


A basic-conversation message consists of the 
sequence of logical records transferred in 
one direction from one TP to another without 
an intervening change of direction or confir- 
mation. (The Attach FM header generated from 
the ALLOCATE verb is also considered part of 
the initial basic-conversation message. ) 


The end of a conversation message is deter- 
mined, when sending, by a conversation state 
change caused by the verbs issued. For exam- 
ple, PREPARE_TO_RECEIVE, RECEIVE_AND_WAIT, 
CONFIRM, SYNCPT, and DEALLOCATE end a conver- 
sation message. When receiving, the end of a 
conversation message and conversation state 
change 1s determined from corresponding pro- 
tocol information received from the sender. 
The information identifying the end of a con- 
versation message and specifying the way it 
was ended is generically called the 


end-of-conversation-message indication. 


A basic-conversation message is the elementa- 
ry unit for which the LU supports confirma- 
tion or  program-error reporting (e.g.>» 
SEND_ERROR) between sender and receiver, and 
for which it performs purging. 


A mapped-conversation message 1s analogous to 
a basic-conversation message; that is, it 


consists of the sequence of 
mapped-conversation records (or data records) 
transferred in one direction from one TP to 
another without an intervening change of 
direction or confirmation, as understood at 
the mapped-conversation protocol boundary. 


The unqualified term conversation message is 
used when the intended protocol boundary is 
clear from the context, or when both the 
mapped-conversation message and its corre- 
sponding basic-conversation message are 
designated. 


Conversation Exchange 


A conversation exchange consists of the com- 
plete set of mapped- or basic-conversation 
messages transferred between a pair of TPs 
using a particular conversation. 


SESSION MESSAGE UNITS 


Session message units are formatted for LU-LU 
protocols and for effective use of the path 
control network. 


Function Management Headers 


A function management (FM) header is a mes- 
sage unit generated by the LU to carry cer- 
tain LU control information. The LU uses the 
following FM headers: 


e 8 86 An Attach FM header (FMH-5) specifies the 
name and required characteristics, e.g.; 
option sets required, of the target TP. 


e An Error-Description FM header (FMH-7) 
describes a transaction program error or 
Attach failure. 

® A Security FM header (FMH-12) carries 


security information for LU-LU verifica- 
tion. 


Basic Information Unit 


A basic information unit (BIU) is the message 


unit transferred between two LUs. It con- 
sists of a request header (RH) and a 


request/response unit (RU). 


The RH is a formatted prefix to the RU. It 
carries protocol information encoded from the 
TP verbs or generated internally by the LU. 
“Appendix D. RH Formats" gives’ further 
details. 


RUs carry FM headers, TP-supplied data (for- 
matted by the TP or the LU into logical 
records), and other protocol information. 
The LU uses the following RUs on an LU-LU 
session: 


¢ Category FMD RUs, for transaction-program 


data 

® Category DFC RUs, such as BIS, LUSTAT, 
RTR, SIG 

e EXR, for some path-control-detected 
errors 

(For details, see "Appendix E. 


Request/Response Unit (RU) Formats" and "Ap- 


pendix H. FM Header and LU Services 
Commands". ) 
The LUs also transfer other information 


describing the BIU, such as the length and 
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sequence number, which is formatted by path 
control. Path control uses this information 
to build a transmission header (TH). 


SESSION MESSAGE-UNIT SEQUENCES 


The following sequences of BIUs are relevant 
to session protocols: 


A (BIU) chain is a sequence of BIUs that con- 
stitute a single wmidirectional transfer. 
The chain is the most elementary unit that 
can be independently confirmed or for which 
errors can be reported using SNA-defined LU 
protocols. It corresponds to a TP-TP conver- 
sation message. 


A bracket consists of the set of all chains 
transferred on a particular conversation. It 
corresponds to a TP-TP conversation exchange. 
The first data RU in a bracket begins with an 
Attach FM header that identifies the target 
TP. 


The total session traffic comprises a 
sequence of one or more brackets. Prior to 
bracket traffic, the session is activated 
(BIND protocols). Prior to normal session 
deactivation, bracket traffic is shut down 
(BIS protocols). All session traffic stops 
when the session is deactivated (UNBIND pro- 
tocols), whether or not any brackets are in 
transit. 


Figure 2-4 on page 2-17 illustrates the cor- 
respondence between the conversation 
message-unit sequences and session 
message-unit sequences. In the figure: 


e The colum labelled TP-TP shows the con- 
versation message-unit sequences. 


( The corresponding conversation 
message-umit sequences for the partner 
TPs at LU Y are not shown; they are the 
reverse of those shown for TP A and TP 
B.) 


® The colum labelled LU-LU shows the ses- 
sion message-unit sequences. 


® The column labelled LU X shows the 
relationship between the two sets of 
sequences. 


MAPPED-CONVERSATION MESSAGE-UNIT TRANSFORMA- 
TION 


The mapped-conversation support in the LU 
converts a data record into a 6DS variable. 


First, the LU optionally performs = a 
TP-specified mapping transformation on the 
data record, producing a mapped-conversation 
record. If mapping transformations are not 
supported or if one is not specified, the TP 
supplies the data in MCR format (i.e., a con- 
tiguous byte string of TP-determined length). 


The wmapped-conversation support in the LU 
then segments the MCR into units of allowed 
logical-record length and adds LLID prefixes, 
thus producing a 6&DS variable consisting of a 
sequence of logical records. This ts illus- 
trated in Figure 2-5 on page 2-18. 


BASIC-CONVERSATION MESSAGE-UNIT TRANSFORMA-~ 
TION 


Above the basic-conversation protocol bounda-~ 


ry» a TP», or an internal LU component such as 
the mapped-conversation support, generates a 
sequence of logical records constituting a 
conversation message. It passes this conver- 
sation message to the LU as a sequence of 
buffer records, by issuing basic-conversation 
verbs. Along with the buffer records, it 
passes unformatted protocol information such 
as the ALLOCATE verb parameters, from which 
the LU builds FM headers. 


Conceptually, the LU assembles the sequence 
of FM headers and logical records into a com~ 
plete conversation message. It then converts 
this conversation message into a chain of 
BIUs. Of course, the LU does not necessarily 
store a complete conversation message at one 
time; when it accumulates enough buffer 
records to build one or more BIUs, it builds 
those BIUs and sends them out, saving any 
residual data for the next BIU. 


To build BIUs, the LU reblocks the FM headers 
and logical records into RU-sized units and 
generates the necessary RHs. The LU sets the 
RH indicators to correspond to functions or 
states specified by verb parameters; for 
example, it sets the chaining indicators 
(BCI, ECI) to indicate the first and last 
BIUs in the chain, and it sets the bracket 
indicators (BB, CEB) to indicate the first 
and last BIUs in a bracket. When necessary, 
the LU also generates Attach or 
Error-Description FM headers (FMH-5 = and 
FMH-7) from verb parameters and = includes 
these in the BIUs. The final result is a BIU 
chain. Along with the BIU, the LU ganerates 
parameter values for use by path control (to 
build the transmission header). The LU 
transfers the BIUs and the unformatted BIU 
parameters to path control for transmission 
to the partner LU. Figure 2-6 on page 2-19 
illustrates the conversion process. 


DATA EXCHANGE WITH OTHER NAUS 


The LU also exchanges message units with oth- 
er NAUs, specifically with the CP, via the 
CP-LU session, and with the PU, directly. 
These message units are listed in "Chapter 4. 
LU Network Services" and are described brief- 
ly below. 


LU-CP Message Units 


The LU sends session services RUs on the 
CP-LU session. These RUs are used in the 
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Figure 2-4. Relationships of Sequences of Message Units (Example) 
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GDS Variabl 


LEGEND: 
data record: data supplied by the transaction program MC_SEND_DATA verb (arbitrary format) 
length: length of the mapped-conversation record (after mapper transformation, if any) 
LL: logical-record Length field; the first bit is the continuation field 
ID: GDS ID field 


Figure 2-5. Relationship of Data Records to Logical Records (Example) 


session-initiation protocols for LU-LU ses- The LU generates and uses session control RUs 

sions, e.g.» for translating the partner LU for session activation and deactivation. It 

name into the network address. In some sends these to the PU for routing to the 

cases, the choice of RUs depends on the type remote LU. 

of node (subarea or peripheral) containing : 

the sending LU. | Another group of LU-PU internal records is 
used to connect the LU to other node compo- 

The LU also uses the CP-LU session to send nents or to reset the LU. 


and receive maintenance services RUs. 
LU-PU Records 


The LU has a direct protocol boundary with 
the PU in its node. 
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LEGEND: 
LR: logical record LL: Length field ID: GDS ID field 
RH: request header RU: request unit BIU: basic information unit 
FMH—5: Attach FM header (occurs only on first conversation-message of conversation) 
Attach values: information for the Attach FM header, from the ALLOCATE verb. 
TH values: protocol information generated by the LU; the TH is built by path control. 


Figure 2-6. Relationship of Conversation Message to BIU Chain (Example) 


This section illustrates the correspondence The correspondence is illustrated in Fig- 


between some typical  basic-function-set ure 2-7 on page 2-21 through Figure 2-23 on 
transaction program verb sequences and the page 2-28. In the figures, the left column 
resulting flows of BIUs through the path con- shows verbs issued by the invoking or 
trol network. (The verbs are described in initially-sending TP, and the right column 
detail in SNA Transaction Programmer's Refer- shows verbs issued in response by the invoked 
ence Manual for LU Type 6.2). or initially-receiving TP. The center column 


shows the contents of the resulting chain (RH 
indicator settings, RU data and FM headers). 
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The arrows indicate direction of BIU flow. A 
group of arrows in the same direction repres- 
ents a chain, but no necessary correspondence 
exists between arrows in the figures and BIUs 
in the chain. 


Each figure shows one of the following: 


¢ The beginning of a chain, for chains that 
begin a bracket 


°® The end of one chain and the beginning of 
the next 


® The end of a chain, for chains that end a 
bracket 


"Allowable Combinations of Sequences" on page 
2-23 shows how these flows can be combined, 
or sequenced, to form complete conversations. 
Finally, "Error Flows" on page 2-25 shows 
asynchronous response cases. 


NOTATION 


The following notation is used in the fig- 
ures. 


> Request RU 
+ Shee Response RU 
RH indicators: 


The flow is labeled with the indicator values 
that are carried in the RH. 


BB Begin bracket | 

CEB Conditional end of bracket 
BC Begin chain 

EC End chain 


RQEL Request exception response 1 


RQE2 Request exception response 2 (in this 


case, DRII = DRII-DR1; ji.e., RQE3 is 
equivalent to RQE2). 


RQ01 Request definite response 1 

RQD2 Request definite response 2 (Cin this 
case, DRII = DRII-DR1; ji.e., RQD3 is 
equivalent to RQD2). 

co Change direction 

+DR2 Positive response to RQD2 

~RSP(0846) Negative response to chain 

RU contents: 

FMH-5 Attach FM header 

FMH-7 Error-description FM header 


The sense-data categories shown are: 


0864 © Abnormal deallocation 
0889 Program-detected error 


data User data in FMD RU 
Verbs and Parameters 


The returned RETURN_CODE parameter of the 
RECEIVE _AND_WAIT verb is not shown ohen it is 
set to OKs in that case, the returned 
WHAT_RECEIVED parameter is shown instead. 


DATA_* represents either setting (DA- 
TA_COMPLETE or DATA_INCOMPLETE) of this 
parameter. 


Data Transfer Description 


Whenever a TP has the right to send, it 
tissues SEND_DATA zero or more times. Simi- 
larly, a TP in receive state repeatedly 
issues RECEIVE_AND_WAIT, until it receives 
all of the data and the 
end-of-conversation-message indication. The 
receiver issues at least one receive verb; in 
the absence of errors, zero or more initial 
issuances of SEND_LDATA by the source TP 
result in zero or more receive verb issuances 
(with WHAT_RECEIVED = DATA_INCOMPLETE) at the 
target. The final issuance receives the 
end-of-conversati on-message indicator as 
WHAT _RECEIVED = DATA_CONPLETE. Since the 
buffer record sizes used at the sending TP 
and at the receiving TP may differ, the nun- 
ber of receive verb issuances does not neces- 
sarily match the number of send = verb 
issuances. 


All of the following figures begin or end 
with the data-transmission sequence just 
described. That sequence is represented in 
the figures as follows. 


When the figure begins with (the end of) the 
data-transmission sequence, it shows (at the 
sending TP) a single SEND_DATA verb, and a 
corresponding data arrow, folloned by verti- 
cal (two-dot) ellipsis marks (:). No 
RECEIVE_AND_WAIT verb is shown at the 
receiving TP. 


When the figure ends with (the beginning of) 
the data-transmission sequence, it shows (at 
the receiving TP) vertical ellipsis marks 
(:), followed by a single RECEIVE_AND_ WAIT 
verb with WHAT_RECEIVED = OATA_COMPLETE. 
"Data" is shown on the corresponding arrow, 
along with the end-of-conversation-message RH 


indicators. No SEND_DATA verb is shown at 
the beginning of the receiving-TP verb 
sequence. 7 


ERROR-FREE FLONS 


The error-free flows for the base function 
set flows are described in terms of the verb 
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sequences shown in Figure 2-7 on page 2-21 
through Figure 2-14 on page 2-23. 


SEQUENCE 1 


ALLOCATE 
SYNC_LEVEL( NONE ) BC,BB,FMH-5 
> (TP started) 
SEND_DATA data 
> 


e e 
@ e 


Figure 2-7. Start Conversation without Confirmation 


SEQUENCE 2 
PREPARE_TO_RECEIVE EC,RQE1,CD,data RECEIVE _AND_WAIT 
TYPE( FLUSH ) anna a WHAT_RECEIVED=DATA_COMPLETE 
RECEIVE_AND_WAIT 
WHAT_RECEIVED=SEND 
BC, data SEND_DATA 


« e ° 
e@ e e 


Figure 2-8. Conversation Turnaround without Confirmation: PREPARE_TO_RECEIVE is optional; when it 
is omitted, and a ereceive verb is issued from SEND state, the function of 
PREPARE_TO_RECEIVE is performed before any data is actually received. 


SEQUENCE 3 
DEALLOCATE EC, RQE1,CEB,data RECEIVE_AND_WAIT 
TYPE( FLUSH ) $e > WHAT_RECEIVED=DATA_COMPLETE 
(local deallocation) RECEIVE_AND_WAIT 
RETURN_CODE=DEALLOCATE_NORMAL 
DEALLOCATE 


TYPE( LOCAL) 
(local deallocation) 


Figure 2-9. Finish Conversation without Confirmation 


SEQUENCE 4 

ALLOCATE BC,BB,FMH-5 
SYNC_LEVEL( CONFIRM )———————>_ (TP started) 

SEND_DATA data 


> 


Ad 2 e 
e e e 


Figure 2-10. Start Conversation with Confirmation 
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SEQUENCE 5 
CONFIRM EC,RQD2,-CD,data RECEIVE_AND_WAIT : . 
> WHAT _RECEIVED=DATA_COMPLETE 
RECEIVE_AND_WAIT . 
WHAT_RECEIVED=CONFIRM 


+DR2 CONFIRMED 
RETURN_CODE=0OK < 


SEND_DATA BC, data 


e 
« 


Figure 2-11. Continue Conversation: Confirmation without Turnaround 


SEQUENCE 6A 


« * 


PREPARE_TO_RECEIVE 7 RECEIVE_AND_WAIT 
TYPE(SYNC_LEVEL)  EC,RQD2,CD,data | 
LOCKS( SHORT ) $$ > | WHAT_RECEIVED=DATA_COMPLETE 


RECEIVE _AND_WAIT 
WHAT_ RECEIVED= CONFIRM_SEND 
+DR2 CONFIRMED 
RETURN_CODE=0K < 


BC, data SEND_DATA 
Cn ent 


Figure 2-12. Conversation Turnaround with Confirmation, using LOCKS(SHORT): 


When the receiving TP issues CONFIRMED after the LU has received RQD2--indicating 
CONFIRM LOCKS(SHORT)--the LU immediately sends a CONFIRMED response (+DR2). This 
allows the CONFIRM sender to resume processing immediately, so that, for example, it 
can release locks on its local resources. | 


(The receiving LU processes the RQD2 internally; it does not inform the receiving TP of 
the LOCKS parameter value. ) 


SEQUENCE 6B 


PREPARE_TO_RECEIVE RECEIVE_AND_WAIT 
TYPE(SYNC_LEVEL) EC,RQE2,CD,data 
LOCKS( LONG ) —_—_—_—_— OO >-)—C WHAT_RECEIVED=DATA_COMPLETE 


RECEIVE_AND_WAIT 
WHAT_RECEIVED=CONFIRM_SEND 
CONFIRMED 
(LU omits sending +DR2) 


BC, data SEND_DATA 
RETURN_CODE=0K aR 


e ° 


Figure 2-13. Conversation Turnaround with Confirmation, using LOCKS( LONG): 


When the receiving TP issues CONFIRMED after the LU has received RQE2--indicating 
CONFIRM LOCKS(LONG)--the LU does not send an immediate confirmation response. Instead; 
it continues processing until it has a complete BIU to send. The CONFIRM sender 
interprets receipt of BC without an intervening response as positive confirmation. 


LOCKS( LONG) does not require the +DR2 response BIU that LOCKS(SHORT) requires, but it 
can cause the CONFIRM sender to wait longer before resuming processing. 
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SEQUENCE 7 
DEALLOCATE EC,RQD2,CEB,data RECEIVE_AND_WAIT 
TYPE(SYNC_LEVEL) §9———————————>_ WHAT_RECEIVED=DATA_COMPLETE 
RECEIVE_AND_WAIT 
WHAT_RECEIVED=CONFIRM_DEALLOCATE 


+DR2 CONFIRMED 
RETURN_CODE=0K Coe ee ee eee ee 
Local Deallocation DEALLOCATE 
TYPE( LOCAL) 


Figure 2-14. Finish Conversation with Confirmation 


Figure 2-15. 


ALLOWABLE COMBINATIONS OF SEQUENCES 


When a program issues one of the verb 
sequences shown above, that program is Limit- 
ed in its choice of the next verb sequence it 
can issue. The matrix in Figure 2-15 shows 
which verb sequences can follow a given verb 
sequence in the base function set. The 
matrix has the following meaning: 


® The row numbers (left column) and column 
numbers (top row) in the matrix corre- 
spond to the sequence numbers in Fig- 
ure 2-7 on page 2-21 through Figure 2-14. 


A row corresponds to the verb sequence 
just issued; a column corresponds to the 
verb sequence issued next. 


In the matrix, row 0 or column 0 repres- 
ents the state in which no conversation 
exists, i.e., the state prior to ALLOCATE 
or subsequent to DEALLOCATE. 


® A letter N or C in a cell indicates that 
the sequence corresponding to the column 
number can follow the sequence corre- 
sponding to the row number. 


- WN--indicates a next sequence allowed 
for conversations allocated with 


Ra ba 
Kak 


Possible Next Sequence in Error-Free Cases 


either SYNC_LEVEL( NONE ) or 
SYNC_LEVEL(CONFIRM), i.e.5 conversa- 
tions started with sequences 1 or 4 


- C--indicates a next sequence allowed 
only for conversations allocated with 
SYNC_LEVEL(CONFIRM), i.e.) conversa- 
tions started with sequence 4 


-  empty--indicates that the correspond- 
ing sequence order is invalid 


e The Next-Sender column indicates which TP 
is initial sender (ji.e., issues the verbs 
in the left column of the figure) for the 
next sequence: 


-  SAME--the initial sender of the next 
sequence is the same as the initial 
sender of the previous sequence. 


~-  OTHER--the initial sender of the next 
sequence is the partner of the ini- 
tial sender of the previous sequence. 


Figure 2-16 on page 2-24 and Figure 2-17 on 
page 2-24 illustrate the application of these 
rules to generate allowable conversation 
sequences. _ 
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ALLOCATE 


SYNC_LEVEL(NONE) BC,BB,FMH-5& 
> (TP started) 
SEND_DATA data RECEIVE_AND_WAIT [NOTE 1--see text] 
$$ > HHAT_RECEIVED=DATA_* 


SEND_DATA RECEIVE AND_WAIT 
DEALLOCATE EC,RQE1,CEB,data WHAT_RECEIVED=DATA_COMPLETE 
tye ECF LUSH) ee > RECEIVE AND WAIT 
(local deallocation) RETURN_CODE=DEALLOCATE_NORMAL 
DEALLOCATE 
TYPECLOCAL ) 


(local deallocation) 


Figure 2-16. One-Way Conversation without Confirmation: Combines Sequences 1 and 3 


The sequence shown in Figure 2-16 is gener- SEND_DATA and one additional issuance of 
ated as follows: RECEIVE_AND_WAIT. 

1. Begin in state 0. 4. Select a column containing an N in row 1. 
2. Select a column containing a lettered In this example, column 3 was chosen. 


cell in row 0. 
5. Orient sequence 3 according to the "next 
In this example, column 1 was chosen. sender" column for the previous sequence, 
This corresponds to sequence 1. 
In this example, the next sender is SAME; 


3. Supply an arbitrary number of SEND_DATA so the left column of sequence 3 is 
and RECEIVE_AND_WAIT verbs’ following issued by the same TP as the left column 
sequence 1, as allowed by the the of sequence 1. 


data-transfer convention. 

6. Select a column containing an N in row 3. 
In this example, the ellipsis was The only choice is column 0, indicating 
replaced by one additional issuance of the end of the sequence. 


ALLOCATE BC,BB,FMH-5 


SYNC_LEVEL( CONFIRM) ———————————-> (TP. started) 

PREPARE_TO_RECEIVE EC,RQE2,CD RECEIVE_AND_WAIT 
TYPE(SYNC_LEVEL) © —————————————> ss WHAT_RECEIVED=CONFIRM_SEND 
LOCKS( LONG) CONFIRMED 


BC,data SEND_DATA 
RETURN_CODE=0K mene 
RECEIVE_AND_WAIT 
WHAT_RECEIVED= EC,RQD2,CEB,data DEALLOCATE 
DATA_COMPLETE <———————____—_- TYPE(SYNC_LEVEL ) 
RECEIVE _AND_WAIT 
WHAT_RECEIVED= 
CONFIRM_DEALLOCATE 
CONFIRMED +DR2 
ahead aleeateeataahetetetetetaaies > RETURN_CODE=0K 
DEALLOCATE 
TYPEC(LOCAL ) 


Figure 2-17. Two-Way Conversation with Confirmation: Combines Sequences 4, 6B, and 7. 


The sequence shown in Figure 2-16 is gener- 2. Supply some number of SEND_DATA and 
ated as follows: RECEIVE_AND_WAIT verbs following sequence 
4. 


1. Beginning in state 0, select sequences 4, 
6B, and 7, returning to state 0. In this example, 0 instances of SEND_DATA 
were chosen. Thus, following the data 
transfer convention, the SEND_DATA verb 
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SEND_DATA data 
SEND_DATA 


REQUEST_TO_SEND_RECEIVED=YES 


PREPARE_TO_RECEIVE EC,RQE1,CD,data 
TYPE( FLUSH ) ~ 
RECEIVE _AND_WAIT BC, data 


WHAT_RECEIVED=DATA_* 


°° 


Figure 2-18. 


and data arrow in sequence 4 are elimi- 
nated, as iS the RECEIVE_AND_WAIT 
WHAT_RECEIVED = DATA_COMPLETE and _ the 
data on the EC arrow in sequence 6B. 


3. The next sender following sequence 4 is 
SAME; therefore, sequence 6B has the same 
orientation as the preceding sequence. 


4. Supply some number of SEND_DATA and 
RECEIVE_AND_WAIT verbs following sequence 
6B. 


In this example, only one instance of 
each was chosen, corresponding exactly to 
the number in the sequence figures. 


(This figure illustrates that the ari-ows 
do not necessarily corressund to BIUs. 


e 


oe 


For example, the CONFIRM, SEND_DATA, and 
DEALLOCATE might generate only one BIU, 
even though two arrows are shown in the 
figure. ) 


5. The next sender following sequence 6B is 
OTHER; therefore, sequence 7 is reversed 
to have the opposite orientation from 
that of the preceding sequence (i.e., 
since the left column of sequence 6B cor- 
responds to the left column of the com- 
bined sequence, the left column = of 
sequence 7 corresponds to the right col- 
umn of the combined sequence). 


6. The next row number is 0: therefore this 
completes ine sequence. 


RECEIVE_AND_WAIT 


> WHAT_RECEIVED=DATA_* 


< 


BC,EC,SIGNAL (expedited flow) REQUEST_TO_SEND 
RECEIVE_AND_WAIT 


> WHAT_RECEIVED=DATA_COMPLETE 


RECEIVE_AND_WAIT 
WHAT_RECEIVED=SEND 


< 


@ e . 
e e 


SEND_DATA 


Conversation Turnaround following REQUEST_TO_SEND (without Confirmation): 


REQUEST_TO_SEND issued by the receiving TP results in an expedited-flow one-RU chain. 


The TP sending data 
subsequent verb. 


is notified via the REQUEST_TO_SEND_RECEIVED parameter of a 
The interpretation of REQUEST_TO_SEND_RECEIVED is determined by the 


TP. In this example, the sending TP stops sending and issues RECEIVE_AND_WAIT. 


EXCEPTION FLOW 


Figure 2-18 illustrates the only non-error 
case for which a TP can send while in receive 
state. This flow represents issuing the 
REQUEST_TO_SEND verb and sending the SIGNAL 
RU. 


This flow can be substituted for sequence 2. 
A similar sequence corresponding to sequence 
6A or 6B exists, but is not illustrated here. 


ERROR FLOWS 


Figure 2-19 on page 2-26 through Figure 2-23 
on page 2-28 illustrate flows resulting from 
transaction-program error recovery for the 
base function set. When the TP detects a 
TP-defined error (e.g., the received data 


fails an application validity check, or the 
partner sends more logical records than 
expected) it issues SEND_ERROR or DEALLOCATE 
TYPECABEND}. When the LU detects a trans- 
action program error, such as an Attach fail- 
ure, 1t generates similar flows. 

Three cases exist: 


¢ Verb issued by sender 
® Verb issued by receiver 


e Verb issued by both (e.g., a SEND_ERROR 
race has occurred) 


(This case is not illustrated for DEALLO- 
CATE.) 


For cases not shown here, see ''Component 
Interactions and Flow Sequences" on page 
2-50. 
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SEND_DATA 


e 
e 


(TP detects - RECEIVE ANO_WAIT 

an error ) , 

SEND_ERROR data ; 
right 4 a neemnermemencemeeemee > WHAT RECEIVED=DATA_INCOMPLETE 
SEND_DATA FMH~7(0889),data : RECEIVE AND WAIT 


>  WHAT_RECEIVED=PROGRAM_ERROR_TRUNC 


Figure 2-19. SEND_ERROR Issued by Sender: 


The SEND_LERROR verb forces sending of accumulated data and begins a new RU with an 
FMH-7. The issuing TP remains in send state; it can, for example, send additional 
TP-determined data to further describe the error. 3 


ITER ATT ELE LET LT II IE EEE TO SEE EE SPE EAE LEIA LIC ELE DELIA IEEE IEEE DE SSFDC ANE SIDED OLE LAL ELE ENE TINSEL EEE LOE L IIT ELVES ELE LIES LE NOTIONS TOE IESE LEAE EEOC LL SATION LLL L ORES REEVES EL ERED WEEDON IDO TELEE IDEA AER ELAR EEO LEAL IIE EDA LDA LTE OLEAS ALOE ELLEAE SLA DEAE LE DCE DELLE ODL LED IODIDE POTD DCP EDEL LTE ITED EDL GELS LEIA ELE LEE ILE 
* ° ° 
° 


SEND_DATA data RECEIVE_AND_WAIT 
renee enrenenememarnmecvecemecnaanaremcer WHAT _RECEIVED=DATA_* 
(TP detects an error) 
-RSP( 0846 ) SEND_ERROR 
| macro | 
SEND_DATA data] Purge incoming BIUs 
———— | > to end of chain 
| oe 
e i @ a e 
(LU ends chain) <----- — i” 
EC, RQE1,CD,no data ae 
oe ntceenteeraccmneintcemnamrecctm JP " (LU detects end of chain) 
RETURN_CODE=0K 
BC, FMH-7(0889),data SEND_DATA 
Eee emnenen sen consremaraarremsustenstsmasasasteiemmeaeuammannienasipnesnaesan? 
RETURN_CODE= 


PROG_ERROR_PURGING 
RECEIVE_AND_WAIT 


® 
e ° 


Figure 2-20. SEND_ERROR Issued by Receiver: 


The SEND_ERROR verb causes a negative response to the incoming chain; the sending TP 
sends End-of-chain and Change-direction when it receives the response. Meanwhile, the 
receiver purges incoming RUs until the End-of-chain indication is received, then it 
sends FMH-7 and leaves the issuing TP in send state so it can, for example, send 
additional TP-determined data describing the error. ; 
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e e e 


SEND_DATA data RECEIVE_AND_WAIT 


> WHAT_RECEIVED=DATA_* 
(TP detects an error) 


(TP detects ~RSP( 0846 ) SEND_ERROR 

an error ) puters e sce ree 

SENOD_ERROR data | Purge incoming BIUs 
—— | > to end of chain 

SEND_DATA FMH-7(0889),data ie 


} oe 
° 
e 


| rT) 
(LU ends chain) <----/ " 
EC,RQE1,CD,no data us 
nn enernrnmenennne " (LU detects end of chain) 
RETURN_CODE=0K 
BC, FMH-7(0889),data SEND_DATA 


< 
RETURN_CODE= 
PROG_ERROR_PURGING 
RECEIVE_AND_WAIT 


4 J 
e e e 


Figure 2-21. SEND_ERROR Issued by both Sender and Receiver (SEND_ERROR Race): 


Each LU begins SEND_ERROR processing as in the no-race case, but since the receiver is 
purging to end of chain, the SEND_ERROR from the sender is also purged, so the 
receiver's SEND_ERROR takes precedence. 


SEND_DATA RECEIVE AND_WAIT 
DEALLOCATE data 
TYPECABEND_PROG) ——————_____________—_—_—> WHAT_RECEIVED=DATA_* 
EC ,RQD1,CEB, FMH~7( 0864 ) RECEIVE _AND_WAIT 
ae nenereneeennennnnncneens J RETURN_CODE= 
+DR1 DEALLOCATE_ABEND_ PROG 
(response used <--<------<----~6--- <== 
internally) 


Figure 2-22. DEALLOCATE ABEND Issued by Sender: 


The flow is similar to SENO_ERROR in send state. The +DR1 response is required for 
internal processing. 
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ae 


SEND_DATA data RECEIVE AND _WAIT 
> WHAT_RECEIVED=DATA_* 
~RSP( 0846 ) DEALLOCATE 
Seles =e TYPE( ABEND_ PROG) 
SEND_DATA data] Purging 
| > iT 
| rT) 
(LU ends chain) <--~—J " 
EC ,RQE1,COD>,no data " 
———$ > "(LU detects end of chain) 
BC,EC,RQD1,CEB, FMH-7( 0864) 
cele 
RETURN_CODE= 
DEALLOCATE_ABENOD_PROG 
+DR1 


Figure 2-23. 


e 
° 


DEALLOCATE ABEND Issued by Receiver: 


The flow is similar to SEND_ERROR in receive state. 


internal processing. 


(response used internally) 


The #DR1 response is required for 
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TR 


TURE 


Figure 2-24 on page 2-29 illustrates the 
structure of the LU. 


The upper protocol boundary of the LU is the 
transaction program protocol boundary (de- 
scribed in SNA Transaction Programmer's Ref- 
erence Manual for LU Type 6.2). A 
transaction program processes end user data; 
and requests LU services to commmicate with 
other transaction programs. 


The lower protocol boundary of the LU is the 
path control protocol boundary, below which 
is the SNA path control network, which the LU 
uses to communicate with other LUs and with 
its control point (CP). 

The LU also has a protocol boundary with the 
PU (see "Chapter 4. LU Network Services"). 
SNA LAYERS 


The LU contains 
four SNA layers: 


instances of the following 
Transaction services 
Presentation services 


Data flow control 


Transmission control 


Component Overview 


The LU has two layers of components, one for 
its upper protocol boundary with transaction 
programs, and one for its lower protocol 
boundary with the path control network. Each 
layer consists of a group of processes con- 
taining a pair of SNA layer-instances, and a 
manager component that creates, destroys, and 
otherwise manages these instances. . 


The upper layer contains transaction proc- 
esses, which contain instances of the follow- 
ing SNA layers: 


Transaction services 
Presentation services 


More concretely, each transaction process 
contains an execution instance of a trans- 
action program and some Presentation Services 
components for processing the verbs issued by 
it. (See Figure 2-25 on page 2-30.) 


This layer is managed by the resources manaq- 
er component (RM), which creates transaction 
processes (in response to Attaches received 
from remote LUs), destroys them after they 
have finished executings and connects them 
with sessions (thus enabling’ them to partic- 
ipate in distributed transactions). 
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® Application 
Transaction 
Program 


Control- > Control Operator 
Operator 


Transaction 
Program 


> 
> 
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i 


DIA ° 
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Service 
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Programs 
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Presentation Services 


Resources 
Manager 


A 
< 
PU <————= > 
LU a | ey 
Network [oy V ° 
Services ° 
@ 
PNCP—LU SSCP—LU Control 
Hal f— Hal f—- 
Session Session Transmission 


Services Manager LU-LU Half—Session 


Vv V Vv 
LEGEND: PATH—CONTROL NETWORK 
<————-> SEND/RECEIVE relationship 
<....> CALL/RETURN relationship 
CNOS: Change Number of Sessions RESYNC: Syne Point Resynchronization 
SNADS: SNA Distribution Services DIA: Document Interchange Architecture Services 


Figure 2-24. Overvien of LU 6.2 Components 


— -aw. 
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i SCRA SOC ae & OS wee 


° 
e 
e 
e 
e 
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Transaction Program 


any verb issued 


PS_INITIALIZE PS Verb Router V 
: A : OA > OA 
+S ceeds t—s tos / 
A Vo: ¥ Vo: 
| other 
PS for PS for PS for PS PS for 
Mapped Syne Point Control verb Basic 
Conversations] Services Operator 
PS .MC PS.SPS PS.COPR}| ¢ @ @ 
. / / 7 
V V 


Resources Manager 


LEGEND: 

eoeee> CALL/RETURN relationship (within a process) 

< > SEND/RECEIVE relationship (between processes ) 
NOTE: 


Figure 2-25. 


Half-—Session or 
Resources Manager 


PS verb router is called recursively by PS verb handlers. 


The lower layer contains half-sessions (HSs);, 
which contain instances of the following SNA 
layers: 


Data flow control 


Transmission control 


Half-sessions enforce protocol rules for con- 
versation data exchange, and transform mes- 
sage units between the format useful to 
conversing programs and the format appropri- 
ate for the Path Control network (this 
includes implementing session services such 


FUNCTIONAL SUMMARY BY FUNCTION 


2-30 


This is the first of two sections describing 
the functions and interactions of LU compo- 


nents. This section is organized by func- 
tion; it concentrates on = functions that 
involve multiple components. For each func- 
tion, it explains in approximate time 


sequence the roles of the various LU compo- 


nents. The next section 1s organized by com- 
ponent, and covers’ functions performed 
principally by one component. A full 


description of each component is given in its 
corresponding chapter of this book. 


For illustrations of the component inter- 
actions discussed in this section, including 
a variety of cases not discussed elsewhere in 
this chapter, see "Component Interactions and 
Flow Sequences" on page 2-50. 
Figure 2-34 on page 2-52 and Figure 2-35 on 
page 2-53 illustrate the interactions, at the 
source and target LUs, respectively, for a 


In particular, | 


Structure of a Presentation Services Process 


as pacing and cryptography). While most of 
these are LU-LU half-sessions for transport- 
ing conversation data, one of them must be a 
CP-LU half-session connecting the LU to its 
Control Point. 


This layer is managed by the LU network sServ- 
ices component (LLNS), which creates and 
destroys half-sessions and interacts with SNA 
components outside the LU (the control point 
and the nodal NAU manager in the PU). 


The resources manager and LU network services 
components are created by the PU when it 
activates the LU; they run continuously 
thereafter. 


typical conversation; Figure 2-36 on page 
2-54 and Figure 2-37 on page 2-55 illustrate 
typical interactions for session deacti- 
vation. 


The LU manages the state and configuration of 
its local resources, including transaction 
programs, conversation resources,» and 
half-sessions. It cooperates with other LUs;, 
using shared sessions and conversations, to 
configure these resources to support distrib- 
uted transactions. (An LU implementation 
might also manage other, non-SNA, resources 
such as processor execution cycles, storage, 
and data bases. ) 


The principal functions leading to LU trans- 
action processing are the following, not nec- 
essarily performed in this order: 


® Activating sessions between two LUs 
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® Invoking transaction programs 


® Initiating conversations between the 
transaction programs 


® Transferring message units between the 
transaction programs 


EXAMPLE TRANSACTION PROGRAM 


Figure 2-26 outlines some typical verb issu- 
ances for an example pair of transaction pro- 
grams. 


SOURCE TP TARGET TP 
MC_ALLOCATE 


MC_SEND_DATA MC_RECEIVE_AND_WAIT 
se ee 


MC_RECEIVE_AND_WAIT " 
MC_SEND_DATA 
a8 


MC_DEALLOCATE 
MC_DEALLOCATE 


Figure 2-26. Example of Communicating 
Transaction Programs 


The programs, running at different LUs, issue 
complementary sequences of verbs. The LUs 
convert these executed verbs into 
message-unit flows. 


MESSAGE-UNIT TRANSFER 


First, consider transfer of message units. 
Assume that two transaction programs are run- 
ning at their respective LUs and are con- 
nected by a mapped conversation. For the 
programs to transfer data» one program must 
issue MC_SEND_DATA verbs while the other 
issues complementary MC_RECEIVE_AND_WAIT 
verbs. 


The TP invokes PS for each 
transaction-program verb it issues. PS per- 
forms the function appropriate to the specif- 
ic verb. For each verb, PS verifies that the 
verb is valid in the current conversation 
state, converts the verb parameters to an 
intermediate representation, and performs 
verb-specific processing that includes issu- 
ing appropriate requests to other LU compo- 
nents. 


When sending» PS transforms the 
mapped-conversation record (MCR) into logical 
records, determines message-unit sequence 
boundaries such as the end of a conversation 
message, and passes the data and control 
information to HS. HS converts the logical 
records into one or more RUs, encodes the 
protocol information into the RH; and passes 


the resulting BIU and TH information to path 
control. 


When receiving, HS checks incoming BIUs for 
format and protocol validity and passes the 
data to PS. When the TP issues a 
RECEIVE _AND_WAIT verb, PS checks the verb for 
validity, waits until HS supplies = the 
requested amount of data, and passes the data 
and protocol information back to the TP. 


The following sections discuss these func- 
tions in more detail. (Figure 2-4 on page 
2-17, Figure 2-5 on page 2-18; and Figure 2-6 
on page 2-19 illustrate the message-unit 
relationships discussed. ) 


Sending Data 


For MC_SEND_DATA, PS verifies that the con- 
versation is in send state. If mapping is 
being performed, PS maps the 
transaction-program data record into a 
mapped-conversation record (see "Mapping 
Function" on page 2-39). It transforms the 
MCR into a sequence of logical records of 
implementation-defined length by segmenting 
the supplied data and prefixing the appropri- 
ate GDS LLID fields. It issues SEND_DATA 
verbs as often as necessary (determined by 
the buffer-record size used by the PS.NC 
implementation) to send all the logical 
records. 


PS (in particular, the PS verb router) is 
recursively callable: it is called by a TP 
when the TP issues a verb, and it is also 
called by verb handlers within PS that them- 
selves issue verbs. For example, the 
mapped-conversation verb handlers in PS typi- 
cally issue one or more basic-conversation 
verbs to perform the function requested by a 
mapped-conversation verb. 


When PS has first entered send state, it 
expects an LL at the beginning of the first 
buffer record. From then on, PS compares the 
accumulated length of the data passed on suc- 
cessive issuances of SEND_DATA to the 
logical-record lengths specified in the LLs, 
thus verifying that the conversation message 
sent ends at a logical record boundary. 


PS accumulates the data from successive buff- 
er records in ane internal buffer of 
implementation-defined length. When the 
buffer is full, PS transfers the data to HS 
with an indication of whether it is the last 
of the data for a conversation message. When 
PS detects the end of a conversation message, 
e.g.» a PREPARE_TO_RECEIVE, RECEIVE_AND_WAIT; 
CONFIRM, SYNCPT, or DEALLOCATE verb was 
issued, PS transfers its remaining accumu- 
lated data with an indication of how the con- 
versation message was ended, @.g.» 
confirmation request, conversation = turn- 
around, or deallocation. It also places the 
conversation in the appropriate state. 


Meanwhile, the HS process, also in send 


state, waits for data from PS. When PS 
passes the data, HS reblocks it into RU-sized 
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units (the RU size for a session is deter- 
mined by BIND negotiation when the session is 
activated). When HS has received more data 
than necessary to fill an RU, it generates an 
RH, builds the BIU, and generates a sequence 
number and other TH information. If session 
a a is being used, HS enciphers the 
ata. 


HS encodes each RH to indicate the beginning 
or end of a bracket (corresponding to a conm- 
plete conversation exchange) and the begin- 
ning or end of a chain (corresponding to a 
conversation message). For all but the last 
BIU in a chain, HS encodes the RH with RQEl. 


For the last BIU for the conversation mes- 
sage, HS encodes the RH with EC (the 
end-of-conversation-message indicator) and 
other indicators selected by PS, such as CD 
(e.g.» PREPARE _TO_RECEIVE verb issued), RQD2 
(e.g., CONFIRM issued), RQD1 (DEALLOCATE 
TYPELABEND]) issued), and CEB (DEALLOCATE 
issued). HS changes the local session state 
accordingly. 


iS passes each completed BIU and the corre- 
sponding TH information to path control for 
transmission to the receiving HS in the 
remote LU. 


HS enforces session-level pacing. The send- 
ing HS sends at most one pacing window of 
BIUs before receiving a pacing response. It 
then requires a pacing response from the 
receiver before sending another window. The 
receiving HS sends a pacing response when it 
can receive another pacing window, e.g., when 
it has enough free buffers. Depending on its 
ability to receive additional data, the 
receiver may send a pacing response at any 
time after receiving the first BIU of a win- 
dow. 


Receiving Data 


The HS process at the receiving LU receives 
BIUs and TH information from path control. 
It sends pacing responses when it is able to 
receive additional BIUs. If session 
cryptography is specified, it deciphers the 
data. It checks for correct session proto- 
col. It checks BIU sequence numbers” to 
detect lost or duplicate BIUs and to corre- 
late responses with the correct bracket. If 
it detects any protocol error, it abnormally 
deactivates the session, i.e.» it requests 
LNS to issue UNBIND indicating a format or 
protocol error. 


If the BIU is satisfactory, HS sends the 
Attach FM header, if present, to RM, and 
sends all other RU data to PS. HS also sends 
PS an indication of significant state changes 
that were encoded in the received RH such as 
end of a conversation message (End-of-chain), 
enter send state (Change-direction), confir- 
mation request (Definite-response 213) and 
end of : conversation 
(Condi tional-end-of-bracket). HS changes its 
own session state accordingly. 


Meanohile, the receiving TP issues 
MC_RECEIVE_AND_ WAIT verbs to receive the con- 
versation message. Each verb issuance calls 
PS. 


For each WC_RECEIVE_AND_WAIT issuance, PS 
repeatedly (and recursively) issues 
RECEIVE_ANO_WAIT verbs until it receives a 
complete MCR from HS. 


For each RECEIVE_AND_WAIT verb issuance Cin- 
cluding the case in which RECEIVE_AND_WAIT is 
issued directly by a transaction program, 
i.e., for a basic conversation), PS waits for 
the data from HS. As PS receives the data, 
whish includes LL fields, PS accumulates the 
data in an internal buffer, until it reaches 
the end of a logical record (or buffer 
record). While accumulating the data, PS 
Keeps track of the LL fields, to verify that 
the conversation message ends on a logical 
record boundary. | 


When the PS verb handler for RECEIVE _AND WAIT 
returns (recursively) to the PS verb handler 
for MC_RECEIVE_AND WAIT, PS checks the length 
and continuation fields in the Lls to verify 
that a complete MCR has been received, strips 
the 6DS LL and ID fields, and reblocks the 
data into an MCR. (If the TP receive buffer 
carmmot contain the complete MCR, PS passes it 
to the TP in receive-buffer-sized segments, 
i.@., mapped-conversation buffer records. } 


If PS receives an end-of-conversation-message. 


indication, it does not forward this itndi- 


cation to the TP until after all logical 
records and MCRs have been received. It then 
returns the end-of-conversation-message indi- 
cation alone on the next MC_RECEIVE AND WAIT 
verb issued, and places the mapped conversa- 
tion into the appropriate state. | 


Internal Buffering 


Figure 2-27 on page 2-33 illustrates internal 
buffering that the LU may perform during send 
and receive operations. The figure has the 
following meaning. 


Column (A) 


TP send buffer record is the DATA parameter 
(LL and data) of the SEND_DATA verb. 


Column (6) 


PS send buffer is a buffer in the sending PS 
of implementation-defined length Cin this 
example, 6) for accumulating TP data to 
be sent to HS. 


PS-to-HS record is the data transferred to 
HS froma full PS send buffer. 


Column (C) 


HS internal buffer is as buffer in the send- 
ing HS of RU size (in this example, 4) 
that accumulates data from PS until a 
complete RU can be sent. 
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Record 


Data 


(1) | gfedebA 7: g fedcbA: fe — debA 

(2) | ponmlkjiH 9 : ponm lkjitg : Ikji — Hofe 

(3) : (HS defers sending RU) 
(4) srQ 3 : Ss rQponm : rQponm 1kji 

(5) : i*ay ponm 

(6) vuT 3 : vuTs : rQ 

(7) zyxW 4 zy : xNvuTs : xWvu TsrQ 

(8) #0: > fzy tzy xu 

(9) : : , #zy 

(10) : 

| Direction of Flow - 
NOTATION: 


Read data strings 


LL: 


HS 
Internal 
Buffer 


HS~—to—HS 
via 


: Buffer PC 


:(length 6) (length 6):(RU size 4) (RU size 4) 


e 
eo 


right to left to correspond with the order of 


A capital letter represents the start of a logical record 


(i.e., the first 


byte of the LL field.) 


# represents the end-of-conversation-message indication. 
(This is actually coded in the RH, which is not shown in this 


Parenthesized numbers and letters identify rows and columns for 


Figure 2-27. 


: HS—to-PS : PS TP Receive 
: Record : Receive Buffer 

4 : Buffer Record 

: (RU size 4)s(infinite) (length 8) 
/ Data (len) 
: debA : debA 

Hofe H gfedbcA 7 
2 Ukgi : 1kjiH 

: ponm : p onmlkjiH 9 
: TsrQ : T srQ 3 
xWvu xW vuT 3 
tzy # zyxW 4 
: 


flow on the session. 


example. ) 


explanations in the text. 


Internal Buffering in LU Send/Receive Data Operations (Example) 


HS-to-HS via PC is an RU transmitted over RU size, and up to 32,767 bytes for a TP 
the path control network. record. 


Column (D) Notes on the figure: 
HS-to-PS record is a received RU sent from Row (1) 
HS to PS. 
(A) The sending TP sends a 7-byte logical 
Column (E) record (Abcdefg) to PS. 
PS Receive Buffer is an unbounded buffer for (B) PS sends the first 6 bytes (its buffer 
accumulating received data from HS. length) to HS (Abcdef) and retains the 
7th (g), awaiting more data. 
TP Record is the DATA parameter buffer of 
the RECEIVE verb (of length 8 in this (C) HS at the sender receives the 6 bytes 
example).. from PS and sends 1 RU (4 bytes: Abed) 
to path control and retains the remain- 
This example assumes that the FILL parameter ing 2 bytes (ef). 
of the receive verb has the value LL. The | 
buffer and record sizes were selected to sim- (D) HS at the receiver receives the RU (4 


plify the illustration; typical actual sizes 
would be much larger, e.g.» 256 bytes for the 


bytes) and sends the data to PS 
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(E) Meanwhile, the 
RECEIVE_AND_WAIT. 


receiving TP issues 


PS accumulates the data in its buffer 
until it has enough to satisfy a TP 


request, ji.e., enough to fill the TP 
receive buffer or complete a logical 
record. 

Row (2) 


(A) The sending TP sends a 9-byte logical 
record (H...p). 


(B) This forces another 6-byte buffer from 
PS (g...1)3 PS retains the remaining 4 
bytes (m...p). 


(C) HS now has 8 bytes; it sends 1 RU (4 
bytes: efgH) and retains @ (ijkl). 


(D,E) At the receiving LU, this RU completes 
‘the logical record (A...g) at the 
receiver. PS passes the record to the 
TP and retains the first byte of the 

next record (H). 


Row (3) 


(C) HS at the sender still has exactly 
enough data accumulated for one more RU 
(ijkl), but HS does not send this RU 
until forced by arrival of another byte 
or an end-of-conversation-message indi- 
cation. HS always waits with an exact- 
ly full RU so it can incorporate any 
subsequent protocol signals into the 
RH. 


The interpretation of the remaining lines is 
similar. Highlights are given below. 


Row (5) 


(E) At the receiver, the second RU received 


completes the second logical record 
(H...p) at the receiving PS. But since 
the receiving TP buffer is only 8 


bytes, PS can pass only 8 bytes (H...0) 
on the current receive verb. 


Row (6) 


(E) PS at the receiver passes the last byte 
(p) of the second logical record to the 
TP on the next receive verb. 


Rows (8-9) 


(A-C) The end-of-conversation-message indi- 
cation (#) from the sending TP forces 
the sending PS and HS to send all resi- 
dual data in their buffers. This makes 
one more record available to the 
receiving TP. 


Row (9) 


(D,E) When the receiving HS and PS get the 
end-of-conversation-message indication, 
they forsard all residual data as soon 
as possible. The TP gets the last log- 
ical record. 


Row (10) 
(E) The receiving TP gets the 


end-of-conversation-message indication 
alone on the next receive verb. 


TRANSACTION PROGRAM INITIATION AND TERMI- 
NATION 


Before the TPs can exchange message units, 
the TPs must be brought into execution. 


Invoking a Remote Transaction Program 


Assume that a source TP is already in exe- 


cution. It requests invocation of a remote 
TP by issuing the ALLOCATE verb (or 
MC_ALLOCATE, which PS.MC converts into an 


ALLOCATE). It identifies the program to be 
invoked by specifying the remote transaction 
program name and remote LU name, and selects 
the desired transport characteristics by 
specifying a mode name. 
Using the parameters from ALLOCATE, the 
source PS builds an Attach FM header and 
sends it to HS (in some cases, via RM) for 
transmission to the partner LU. When the 
target HS receives the Attach FM header, it 
passes it to its RM. This RM checks some 
parameters in the Attach FM header including 
all security parameters. If a format or pro- 
tocol error is found, the Attach FM header is 
rejected by terminating the session that it 
arrived on. If no format or protocol error 
is found, RM creates a PS process and passes 
it the Attach FM header. The new PS analyzes 
the Attach FM header and, if an error is 
detected, rejects it; othermwise, PS selects 
and loads the specified transaction program 
code, and calls it, placing it initially in 
receive state for the conversation. 


Once a target TP is invoked, it can act in 
turn as a source TP to invoke other TPs. If 
conversation-level security is required by 
the other TPs, the same security user ID that 
initiated the original target TP may be used, 
along with an Already Verified indicator in 
the Attach FM header, or the source TP may 
supply the required security parameters. 


Initiating the Initial Local Transaction Pro- 
ram 


The first TP activated for a distributed 
transaction is initiated in a way = that 
appears to the TP as though it were invoked 
as a target TP by another source TP. To do 
this, the source RM behaves as if it had 
received an Attach: it creates the PS proc- 
ess and generates an Attach FN header to pass 
to PS. These RM actions are triggered by 
implementation-defined means such as issuing 
@ local control-operator verb. 


PS then loads and calls the TP, 
then issue verbs by calling PS. 


which can 
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Terminating a Transaction Program 


A TP ends by returning to PS.INITIALIZE. PS 
then performs any necessary final processing 
(such as deallocating the TP's remaining con- 
versations), and notifies RM. RM then 
destroys the PS process. 


CONVERSATION ALLOCATION AND DEALLOCATION 


A source TP initiates a conversation with a 
target TP by issuing the ALLOCATE (or 
MC_ALLOCATE) verb. 


The source PS satisfies the TP request in two 
steps. 


First, PS sends RM a request to allocate a 
conversation. RM creates aie conversation 
resource and notifies PS. 


Second, PS sends RM a request to assign a 
session to the conversation. When RM has a 
session available for the conversation, RM 
connects the PS process of the issuing TP to 
the HS process of the session and notifies PS 
and HS. PS places the source end of the con- 
versation (where the allocation Nas 
requested) initially in send state. 


If a session is not immediately available, RM 
suspends the issuing process. 


After a session is assigned to the conversa- 
tion at the source LU, PS sends the Attach FM 
header to HS for transmission to the target 
LU. (In some cases, PS sends the Attach FM 
header to RM rather than directly to HS; RM 
then sends it to HS when bidding for the ses- 
sior. ) 


When HS at the target LU receives the first 
BIU of the bracket, it notifies RM. RM 
receives the Attach from HS, creates the con- 
versation resource, and makes it accessible 
to HS and PS. It places the target end of 
the conversation initially in receive state. 


The following sections give further details 
of these functions. 


Selecting a Session 


RM maintains a list of allocation requests 
and a list of free sessions and their con- 
tention polarities. If RM has an allocation 
request and a first-speaker 
(contention-winner) session is free (i.e., in 
between-brackets state), RM allocates that 
session to the conversation. If a 
first-speaker session is not free but a bid- 


der (contention-loser) session is free, RM 
bids for the session. If no sessions are 
free, but the session limits have not been 


reached, RM requests that LNS activate a new 
session. 


Bidding 


RM requests HS to attempt to begin a bracket 
by sending an RU with BB; this is called 
bidding for the session. 


RM always accepts a bid received on a bidder 
session. 


If RM receives a bid on a first-speaker ses- 
sion, RM accepts or rejects the bid depending 
on whether any of its own transactions need 
to allocate the session for use by their oun 
conversation (if they do, then it sends a 
negative response to the bid; otherwise, it 
sends a positive response to the bid). 


Optionally, a negatively-responding RM will 
inform the partner when it is again willing 
to accept a bid. 


Newly Active Session 


When a session becomes newly active, it is 
initially in in-brackets state. If LU-LU 
verification ts active, RM at the primary LU 
creates and sends (via HS) a Security FM 
header (FMH-12) to the secondary LU's RM for 
verification. The LU that activated the ses- 
sion (the primary LU, or BIND sender) has 
first right to send, regardless of the ses- 
sion contention polarity. If RM at the pri- 
mary LU has no unsatisfied conversation 
request when a session becomes active, it 
requests HS to yield the session, 1.e., to 
end the bracket. 


Deallocation 


When PS requests deallocation of the conver- 
sation, HS ends the current bracket, and RM 
deletes the conversation resource and places 
the session in the free-session List. 


SESSION ACTIVATION AND DEACTIVATION 


If RM has a conversation request for a ses- 
Sion but no session is free and the session 
limits have not been exceeded; RM requests 
LNS to activate a new session. RM also 
requests session activation as a result of 
operator commands (such as INITIAL- 
IZE_SESSION_LIMIT). 


Starting a Session 


Starting a session involves the following 
three activity phases: session limits 
initialization; session initiation, and ses- 
Sion activation. 

Initializing Session Limits: Prior to any 
transaction activity, the control operator 


sets limits on the maximum and minimum num- 
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ber, and contention polarity, of active ses- 
Sions with particular partner LUs using 
particular mode names (see "Control-Operator 
Functions" on page 2-38 for details). 


Session Initiation: When LNS receives a ses- 
sion activation request from RM, LNS sends an 
INITIATE session-services RU, containing the 
partner LU name, to its control point, using 
the CP-LU session. 


When the control point receives the INITIATE, 
it translates the LU name ints a network 
address. 


The CP then sends a CINIT RU, which contains 
the network address, the cryptographic key if 
session cryptography is used, and a 
description of other characteristics for the 
to the LU that is to activate the 
session. (The LU that activates a session is 
called the primary LU [PLU]. The PLU is not 
necessarily the LU that requested session 
initiation. ) 


Session Activation: LNS for the PLU receives 
the CINIT and retains the address. Using 
information from the CINIT and from the LU‘'s 
mode table for the requested mode, LNS then 
generates a BIND session-control RU contain- 
ing the desired session parameters. If secu- 
rity is used, the session parameters include 
randomly generated data for LU-LU verifica- 
tion and an indication of the amount of 
conversation-level security support that is 
defined for the secondary LU. Random and 
enciphered data are sent/received only when 
LU-LU verification is active. UNS sends the 
BIND to its local PU for routing to the part- 
ner LU. 


LNS for the LU receiving the BIND (the sec- 
ondary LU or SLU) negotiates the proposed 
session parameters to acceptable values; 
enciphers the received random data based upon 
the LU-LU password; saves the indication of 
the primary LU's conversation-level security 
support for the secondary LU; and creates a 
positive response to BIND that includes an 
indication of the secondary LU's 
conversation-level security support for the 
primary LU, randomly generated data, and the 
enciphered version of the random data 
received in BIND. LNS sends this positive 
response to BIND via its local PU. 


When the positive response to BIND is sent or 
received, the LNS at each end connects a new 
HS process to the path control network. If 
the session uses cryptography, the HSs 
exchange cryptography-~veri fication RUs. 
Then, each LNS notifies its RM that a new 
session is available. If LU-LU verification 
is active, before the new session is avail- 
able for conversations, the primary LU's RM 
enciphers the random data received on the 
response to BIND and returns it to the sec- 
ondary LU's RM for verification. 


If the LUs cannot agree on session parame- 
ters, or the enciphered random data compar- 
ison fails, the session activation fails. 


Session 


Session Outage 


If session outage occurs, LNS notifies RM. 
If a conversation was active on the session, 
RM notifies PS, which notifies the trans- 
action program of conversation failure. RM 
requests LNS to activate another session if 
it has unsatisfied conversation requests or 
an unsatisfied auto-activation limit. 


Ending a Session 


Ending a session involves the following three 
activity phases: operator request, session 
shutdosm, and session deactivation. 


Operator Request: Sessions are not deacti- 
vated in the normal course of transaction 
program processing; they are deactivated only 
upon speci fic request from the 
control-operator transaction program. 


When the LU operator at either end of a ses- 
sion determines that a session is to be deac- 
tivated, the control-operator transaction 
program issues a control-operator verb. The 
control operator can cause sessions to end in 
tno nays. 


The operator can issue a RESET_SESSION_LIMIT 
verb to reset the session limits to 0 for 
specified partner LUs and mode names. The LU 
proceeds with subsequent phases until there 
are no active sessions for the specified 
(LU,mode) pairs. 


The operator can also issue a DEACTI- 
VATE_SESSION verb to deactivate a specific 
session (this might be done, for example, to 
recover from certain error situations). This 
does not change the session limits, however, 
so the LU might activate another session to 
replace it. | 


When PS.COPR receives the verb, it issues a 
session-limit-change notification or 8a 
session-deactivation request to RM. 

Shutdown: When RM receives a 
session-limit-change notification, RM first 
performs drain processing. If the operator 
has requested RESET_SESSION_LIMIT with drain 
indicated, then RM performs no deactivations 
until all requests for allocation of sessions 
with the specified mode name have been satis- 
fied. 


When drain is complete, or when RM receives a 
session-deactivation request, and an affected 
session next enters between-brackets state, 
RM initiates a bracket-termination protocol. 
This consists of an exchange of 
bracket-initiation-stopped (BIS) RUs assuring 
that all brackets have completed at both ends 
of the session, i.e., that no other BIUs are 
in transit between the LUs. 


After receiving BIS, the partner LU drains 
its allocation requests and sends BIS in 
return. 
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When the BIS protocol is complete, the RM 
that initiated the BIS protocol instructs its 
LNS to deactivate the session. 


When LNS receives a 
request from RM, it 
via the local PU, and awaits a 

When the partner LNS receives an 
it unconditionally sends a positive 


Session Deactivation: 
session-deactivation 
sends UNBIND, 
response. 
UNBIND , 


FUNCTIONAL SUMMARY BY COMPONENT 


This section 1s organized by component; it 
reviews the specific functions of each prin- 
cipal component, and describes functions per- 
formed primarily in one component. 


Presentation Services 


PS manages transaction programs and controls 
conversation-level communication between TPs: 


° Loads and calls the transaction program 


e¢ Maintains the conversation protocol 
state, e.g., send/receive state of the TP 


sd Enforces correct verb parameter usage and 
sequencing constraints 


® Coordinates specific processing for each 
verb 


® Performs mapping of transaction program 
data into mapped-conversation records 


® Converts mapped-conversation records to 
GOS variables, and the reverse: it par- 
titions the data into logical records and 
generates LLID prefixes 


® Buffers conversation-message data from 
the transaction program into contiguous 
blocks for efficient subdivision by HS 


® Reblocks RU data from HS into logical 
records or buffer records as required by 
the TP 


® Verifies logical-record length and bound- 
aries 


e Truncates or purges data when errors are 
reported or detected by the TP 


® Generates and issues FM headers’ for 
Attaches and Error-descriptions 


Half-Session 


HS controls -session-level communication 


between LUs: 


e Reblocks data from PS into RU-sized units 


response. When the response to UNBIND is 
sent or received, the corresponding LNS dis- 
connects the half-session process from the 
path control network, notifies the CP that 
the session is ended, and destroys the 
half-session process. 


® Builds RHs and enforces correct RH param- 
eter settings 


® Creates chains and enforces chaining as 
the unit of LU-to-LU error recovery 

® Correlates responses with the correct 

bracket 


® Enforces bracket protocol 
rejected brackets 


and purges 
e Enforces protocols for the relevant FM 
and TS profiles for the session 


¢ Generates and enforces sequence numbering 
to detect lost or duplicate BIUs 


e Provides session-level pacing 


e Exchanges cryptography-verification RUs 
when session cryptography is being used 


® Enciphers and deciphers data when session 
cryptography is being used 

Resources Manager 

RM manages presentation services and conver- 

sations. 


® Creates and destroys instances of presen- 
tation services 


¢ Creates and destroys conversation 
resources and connects them to 
half-sessions and to presentation serv- 
ices 

Finishes LU-LU verification for 


session-level security by generating and 
processing Security FM headers (FMH-1l2s) 


e Performs all conversation-level security 
checks, verifies conversation-level pass- 
words, and controls access to protected 
transaction programs 


¢ Maintains the data structures represent- 
ing the dynamic relationships among con- 
versation resources» half-sessions,» 
transaction program instances, and trans- 
action program code 
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® Chooses the session to be used by a con- 
versation and controls contention for the 
session | 


® Performs drain action: allows session 
traffic to cease before requesting ses- 
sion deactivation 


® Requests LNS to activate and deactivate 
Sessions | 


LU Network Services 


LNS manages sessions: 


e Coordinates session initiation in concert 
with the control point 


® Sends and receives BIND 


® Supplies and negotiates session parame- 
ters during BIND exchange 


® Exchanges cryptographic key and session 
seed 


@ Exchanges random and enciphered data and 
performs initial LU-LU verification 


@ Notifies RM of session outage 


® Notifies the control point of LU charac- 
teristics and conditions during LU 
initialization (ACTLU exchange) 


@® Creates and destroys half-session 
instances and connects them to path con- 
trol instances 


FUNCTIONS OF SERVICE TRANSACTION PROGRAMS 


Service transaction programs provide func- 
tions to the end user that require communi- 
cation with another LU using ae special 
SNA-defined pattern of verbs. 


Service TPs form part of a distributed trans- 
action similarly to other TPs. They have a 
transaction program name and are invoked by 
the Attach mechanism, and they exchange 
information with these other TPs by issuing 
transaction-program verbs. 


Service transaction programs differ from 
user-application transaction programs in that 
they are SNA-defined and are considered part 
of the LU. The names of service transaction 
programs are SNA-defined. The records that 
service TPs send and receive are SNA-defined 
GDS variables. 


Control-Operator Functions 


All LUs have =. an implementation- or 
installation-defined control operator trans- 
action program (COPR TP) that represents the 
LU control operator's interface to the LU. 


Using a program-selected means such as opera- 
tor console input, this TP issues 
control-operator | verbs to perform 
control-operator functions. 


Control-operator verb functions include cre- 
ation and modification of the data structures 
that describe the LU and the LU-accessed net- 
work resources: control points, transaction 
programs, partner LUs, and modes. Other 
control-operator verb functions limit the 
numbers and contention polarities of sessions 
with particular LUs for particular mode 
names, and also determine when sessions will 
be activated and deactivated. 


For an LU that supports parallel sessions, 
there are additional transaction. services 
components for the control operator. These 
LUs contain a change-number-of-sessions 
(CNOS) service transaction program. When 
processing CNOS verbs, the COPR TP at one LU 
exchanges GDS variables with the CNOS service 
TP at its partner to reach mutual agreement 
about limits on the number of parallel ses- 
sions between them. 


(Control-operator functions are discussed in 
further detail in "Chapter 5.4. Presentation 
Services--Control-Operator Verbs" . ) 


SNA Distribution Services 


SNA Distribution Services (SNADS) provides a 
set of verbs that an application TP may issue 
to request asynchronous distribution of data. 


The service is provided by a network of dis- 
tribution service units (DSUs) interconnected 
by conversations and sesstons. Each DSU con- 
sists of PS verb handlers and a collection of 
service TPs within the LU. The service TPs 
provide data storage, routing, and distrib- 
ution asynchronously with the origin or des- 
tination application programs. 


SNADS is described in the publication SNA 
Format and Protocol Reference Manual: Dis- 
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tribution Services. 
Document Interchange Services 


Document Interchange Architecture (DIA) 
describes formats and protocols for synchro- 
nous exchange of documents by using 
basic-conversation verbs in a prescribed may. 
Document interchange services include service 
TPs for synchronous document transfer. 


Document interchange architecture is 
described in the publication Document Inter- 


change Architecture--Concepts and Structures. 


OPTIONAL FUNCTIONS 


This section describes the principal optional 
function sets. 


SNA Format and Protocol Reference Manual for LU Type 6.2 


Mapping Function 


ine mapping function is an optional function 
of mapped conversations (PS.MC) that allows a 
TP to select transformations, called maps, to 
be applied to TP data at the sending and 
receiving TP protocol boundaries. Maps are 
non-SNA-defined transformation tables or pro- 
cedures that can be defined by the installa- 
tion at both the source and target LUs. Maps 
can specify, for example, how fields of a 
mapped-conversation record are related to the 
TP variables (data record) referred to in 
protocol-boundary verbs. 


Each LU can support multiple maps. Each map 
is identified by a map name. The maps to be 
applied are selected by the transaction pro- 
gram (via verb parameters) and by other maps 
(in an implementation-defined way), as shown 
in Figure 2-28 on page 2-40. 


Three separate map-name name spaces exist 
(terms in parentheses correspond to those in 
the figure): 


1. Sender locally-Known map name: This map 
name (map-name-1) is Known to the TPs at 
the sending LU. It identifies a map 
(map-1) at the sending LU that defines 
the transformation performed by the send- 
er from the format of the sending-program 
data (data-1) to the format of the MCR 
(data-2) that is sent on the conversa- 
tion. This map also defines a corre- 
spondence between the sender 
locally-Known map name (map-name-1) and 
the globally-known map name (map-name-2) 
described below. 


2. Globally-known map name: This map name 
(map-name-2) 18 Known at both the sending 
and receiving LUs, and is transferred on 
the conversation between sender = and 
receiver. It tdentifies a map (map-2) at 
the receiving LU. This map defines the 
transformation performed by the receiver 
from the format of the MCR received on 
the conversation (data-2) to the format 
of the data presented to the receiving 
transaction program (data-3). This map 
also defines a correspondence between the 
globally-known map name (map-name-2) and 
the receiver locally-kKnown map name 
(map-name-3) described below. 


3. Receiver locally-known map name: This 
map name (map-name-3) 1s Known to TPs at 
the receiving LU. This identifies the 
format of the data presented to the pro- 
gram (data-3), e.g.» it allows the pro- 
gram to select the correct structure 
definition or format description for the 
data produced by the execution of the 
receiver map (map-2). 


Mapping is performed by a PS.MC component 
called the mapper. 


The mapper at the sender selects the send map 
specified by the sender locally-known map 
name, which is supplied as a parameter of the 
MC_SEND_DATA verb. It performs the send map- 


ping on the TP-supplied data, producing a 
mapped-conversation record. Using the sender 
Map» the mapper also selects the 
globally-kKnown map name. 


The LU sends the globally-known map name over 
the conversation in an SNA-defined map-name 
GDS variable (see "Appendix H. FM Header and 
LU Services Commands"), and sends’ the 
mapped-conversation record in a separate GDS 
variable. 


The mapper at the receiver selects the 
receive map specified by the globally-Known 
map name received. It performs the receive 
mapping on the mapped-conversation record it 
receives, resulting in data formatted for 
presentation to the TP. Using the receiver 
map, the mapper also selects the receiver 
locally-kKnown map name. PS.MC passes the 
receiver locally-kKnown map name and_ (the 
reformatted data to the TP as returned param- 
eter values for the next receive verb issued; 
e.g.» MC_RECEIVE_AND WAIT. 


The receiving TP uses the receiver 
locally-kKnown map name in a TP-determined way 
to interpret the received data. 


The TPs supply or receive a map name parame- 
ter value for each send or receive verb 
issued, respectively. The LU, however, does 
not send another map-name GDS variable if the 
globally-Known map name has not changed from 
that of the previous record sent. To accom- 
plish this, the mapper at each LU retains the 
most recently sent and most recently received 
values of map-name-2 for the conversation 
(the send and receive map names can be dif- 
ferent). The retained values for each direc- 
tion persist until changed or until the end 
of the conversation, regardless of interven- 
ing turnarounds. 


Syne Point Function 


The syne point function allows all TPs proc- 
essing a distributed transaction to coordi- 
nate error recovery and maintain consistency 
among distributed resources such as data 
bases. 


The sync point functions affect protected 
resources. These include conversation 
resources and implementation- or 
installation-designated resources such = as 
data bases. Any changes to a= protected 
resource are logged so that they can be 
either backed out (reversed) if the trans- 
action detects an error, or committed (made 
permanent) if the transaction is successful. 


The transaction programs divide the distrib- 
uted transaction into discrete, synchronized 
logical units of work (LUWs), delimited by 
synchronization points (syne points). (Cor- 
responding syne points occur at each TP par- 
ticipating in the distributed transaction. ) 
LUNs are sequences of operations that are 
indivisible units for the application, 1.e., 
any failure in an LUN invalidates the entire 
LUN (all LUN precessing by all TPs for the 
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map-name-1, data-1 | |  map-name-2, data-2 | | map-name-3, data-3 
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Figure 2-28. Map Name Usage by Mapped Conversations 
transaction), so the transaction is backed Protection Managers: Each protected 
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out to the previous syne point. 


The LU components for the syne point function 
are shown in Figure 2-29 on page 2-41. 


Highlights of the syne point function are 
discussed below. (See "Chapter 5.3. Presen- 
tation Services--Synce Point Services Verbs" 
for details.) 


Syne Point Control: The syne point function 
at each LU is coordinated by PS.SPS. 


For each TP process participating in the dis- 
tributed logical unit of work, the corre-: 


sponding PS.SPS tracks the state of that 
logical unit of work. To do this, PS.SPS has 
protocol boundaries with the TP and with the 
protection managers for each conversation and 
for each protected local resource allocated 
to that TP. 


Logging: When processing a given logical 
unit of work, whenever a TP issues a verb 
that makes any changes to a protected 
resource, the corresponding resource pro- 
tection manager logs the change so that, if 
necessary, the change can be backed out lat- 
er. 


The log manager maintains the log entries for 
each active LUW (i.e., for each active trans- 
action) on non-volatile storage, using 
implementation-defined data-management func- 
tions. The same log is used to record all 
log entries for all the LU resources for the 
LUW. 


Resources Manager: When it creates the PS 
process, RM provides PS.SPS with access to 
the log. RM also logs conversation allo- 
cations, thereby supplementing the work of 
the conversation protection manager. 


In some cases, a transaction program can ter- 
minate normally before its syne point log 
entries are erased. In these cases, RM 
assumes the function of the terminated sync 
point control to complete the protocol and to 
release (forget) the log entries. 


resource, @.g.» .a conversation or a local 
data base, has a protection manager that logs 
Significant state changes during a logical 
unit of work, detects errors affecting the 
integrity of the changes, and commits or 
backs out the changes as determined by the 
sync point protocol. 


The protection manager for a conversation is 
defined by SNA; protection managers for other 
(non-SNA) resources are defined by the imple- 
mentation, but have a similar protocol bound- 
ary to PS.SPS. The protection managers form 
a sublayer between PS verb handlers and the 
resource-control components. 


Syne Point Protocol: At the end of a logical 
unit of work, an application-designated TP 
Initiates syne point. The LUs then carry out 
a protocol involving all local protected 
resources and conversations being used by the 
TP, and all partner LUs and TPs directly con- 
nected by those conversations, to determine 
whether any TP or protected resource detected 
an error in the LUN, and to propagate this 
result to the other LUs and TPs. 


When a TP issues a verb that invokes the syne 
point function (e.g., SYNCPT, BACKOUT) its 
PS.SPS coordinates the syne point protocol. 
PS.SPS exchanges syne point commands, in the 
form of presentation services (PS) headers 
and FM headers, over the TP's conversations 
with other TPs. Each PS.SPS component for 
the transaction performs similar exchanges, 
in turn, with its TP's conversation partners. 
The PS.SPS components also determine the sta- 
tus of local non-SNA resources by exchanging 
appropriate commands across their internal 
protocol boundaries. These exchanges direct 
the protection managers to complete any pend- 
ing log entries for the LUN. 


The syne point protocol culminates with a 
mutual decision among all TPs processing the 
LUW either to commit or to back out the LUN, 


Commitment and Back-Out: When the syne point 
protocol is complete at a particular TP, the 
resource control components use the LUW log 
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NOTES: 


1. Funetion-shipping resource control recursively calls PS to communicate with the partner. 
The conversation used for communication with the partner has its own protection manager. 


2. PS components not relevant to sync point have been omitted from this figure. 
3. A distinct protection manager exists for each conversation resource created by PS. 
4. The non-SNA components are undefined protocol machines (UPMs). 


Figure 2-29. Relationship of LU Components for Syne Point Functions 
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entries to supply the information needed 
(e.g., data base change records) to perform 
the required commitment or back out. They 
then notify PS.SPS to erase the is entries 
for that LUW. 


Resynchronization: An LU failure might occur 
during the sync point protocol, so that some 
LU never receives an expected LUW status 
report. To recover from this case, the other 
LUs can wait until the failing LU is reini- 
tialized, and then the LUs perform a resyn- 
chronization (resync) protocol to complete 
the syne point processing at each LU. Resyne 
uses service transaction programs to exchange 
Sync point status among the LUs. 


When the failing LU is reactivated, the LU 
completes the resync transaction before run- 
ning any other transaction programs that 
require sync point. The resyne service TP is 
initiated by RM at some LU, typically at the 


DATA STRUCTURES 
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The LU maintains data structures representing 
the state and configuration of its resources. 


Some system-definition data structure ele- 
ments represent the LU-accessed network 
resources. These structures describe the 
characteristics of the LU itself, the trans- 
action programs that the LU can run, the 
control-points that serve this LU, the part- 
ner Us with which this LU can communicate, 
and the modes characterizing possible ses-~- 
sions with particular partner LUs. 


Other data structure elements represent the 
dynamic environment created by the LU. The 
principal components of this environment are 
the transaction program instances in exe- 
cution (represented by transaction-program 
processes) the active sessions with other LUs 
(represented by half-session processes), and 
the active conversations (represented by con- 
versation resources). This environment also 
includes the relationships of the dynamic 
components to the  LU-accessed network 
resources and to each other. 


LU-ACCESSED NETWORK RESOURCES 


Figure 2-30 on page 2-43 illustrates the data 
structures that represent the (LU-accessed 
network resources. 


The LUCB structure (and some associated lists 
not shown) describe the local LU. This 
information includes the LU's fully qualified 
name and the set of optional functions (e.g., 
parallel sessions and mapping) that the LU 
supports. The LUCB is also the anchor for 
lists of data structures describing the other 
LU resources. 


A TRANSACTION_PROGRAM structure (and associ- 
ated lists not shown) describe the trans- 


sync point initiator; this TP attaches the 
resync TP at its partners, which continue 
propagating the resync TP throughout the LUs 
that had been processing the distributed 
transaction. 


The first step of the resync transaction is 
to validate the integrity of the LU logs, 
i.e.» to determine that all LUs' logs contain 
consistent entries for the same LUW. To do 
this, the resync service TPs exchange 
Exchange Log Name GDS variables on the con- 
versation. Next, the service TPs exchange 
Compare States GDS variables to determine the 
status of the sync point protocol at the time 
of failure. PS.SPS then uses this informa- 
tion to complete the sync point protocol. 
(See "Appendix H. FM Header and LU Services 
Commands" for the SNA-defined format of the 
Exchange Log Name and Compare States GDS var- 
iables.)} 


action programs at the lecal LU. This 
information includes the transaction program 
name, its current availability status, and 
the set of optional functions (e.g., sync 
point and mapping) that it supports. 


An CPLU_CAPABILITY structure describes a con- 
trol point. This information includes the 
allowed formats of addresses and the set of 
session-services RUs used on the LU-CP ses- 
sion. 


A PARTNER_LU structure describes a remote LU 
(potential partner LU). This information 
includes the remote LU's names: local LU 
name, fully-qualified LU name, and uninter- 
preted LU name. It also includes the set of 
the LU's optional capabilities such as paral- 
lel sessions. The PARTNER_LU structure also 
contains a list of mode descriptions. 


A MODE structure describes a mode. This 
information includes the moda name and the 
set of optional functions that are supported 
by the remote LU on a mode basis, e.g.» sync 
point. It also includes the session parame- 
ters that characterize this mode, such as 
maximum allowed RU size, session-pacing win- 
dow size, and session cryptography parame- 
ters. The mode structure also indirectly 
describes link characteristics: the mode name 
is used by the control-point as the Key to 
tables identi fying the links and routes to be 
used for sessions .for that mode. 


PROCESSES AND DYNAMIC RESOURCES 


Figure 2-31 on page 2-44 illustrates the 
principal data structures and processes, and 
their relationships, that represent the 
dynamic environment. The formal description 
represents these relationships in various 
ways such as pointers between control blocks, 


SNA Format and Protocol Reference Manual for LU Type 6.2 


LUCB 


TPGM 


LEGEND: 


Vertical lines represent lists of subordinate resources 


TPGM 


PTNR 
PTNR 


PTNR 


Abbr. Data Structure Name 
LUCB: Local LU information (LUCB) 

TPGM: Transaction Program Code information (TRANSACTION_ PROGRAM) 
CPC: Control Point information (CPLU_CAPABILITY ) 
PTNR: Partner LU information ( PARTNER_LU) 

MODE: Mode information (MODE ) 


Figure 


2-30. LU Static Data Structures (Example) 


keys of elements in lists, and intermediate 
dynamic control blocks. 


The processes also contain state information 
used by LU functional components; this is 
described in wore detail in chapters con- 


cerned with the relevant functional compo- 
nents. 


The TP process represents a transaction pro- 
gram instance. It identifies the transaction 
program code that it is using. There may be 
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Vertical lines represent lists of subordinate resources 
sis: association of process to static data elements 
##H#H association of processes via RCB dynamic data element 
¥¥*¥*% association of RCB with MODE in lieu of unavailable HS 
Abbr. Data Structure Name 
LUCB: Local LU information ( LUCB ) 
TPGM: Transaction Program Code information ( TRANSACTION_PROGRAM }) 
CPC: Control Point information (CPLU_CAPABILITY ) 
PTNR: Partner LU information (PARTNER_LU) 
MODE: Mode information (MODE ) 
TP: Transaction program process 
RCB: Conversation resource information (RCB) 
HS: Half—session process 
Figure 2-31. LU Dynamic Dria Structures and Processes (Example) 
multiple transaction program processes exe- The HS process represents a half-session. It 
cuting the same transaction program code. | identifies the remote LU and mode with which 


it is assoctated. <A mode may be associated 
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LU STARTUP AND SHUTD 


with many half-session processes, but each HS 
process 1s associated with only one mode. 


The RCB structure represents a conversation 
resource. The RCBs are the central elements 
in the dynamic configuration of the LU: they 
represent the connection of a transaction 
program to a half-session; this connection is 
dynamically created and destroyed, and allows 
an asynchronous (SEND/RECEIVE) relationship 
between TP and HS. The RCB identifies the 
local TP using the conversation and the 
half-session being used, if any. Because a 
session might not be immediately available 
when a TP allocates a conversation, the RCB 
also identifies the remote LU (PARTNER_LU) 
and mode name (MODE) for the desired session. 
Many conversation resources, hence RCBs, may 
be associated with the same local TP, but 
each RCB may be associated with only one 
local TP, one partner LU, one mode, and one 
half-session. 


Figure 2-31 on page 2-44 illustrates several 
of the possible relationships among these 
structures. In the figure: 


e An active session is associated with the 
control-point (CPC). 


(This session is used directly by LU 
internal components, so no relationship 
to a transaction program is shown. ) 


e RCB CE associates active TP A for trans- 
action program code 1 with mode name U, 
awaiting a free session with mode name U. 


e Active TP B for transaction program code 
2 has two active conversations: 


ad 


LU startup consists of four phases: creating 
the LU processes, activating the CP-LU ses- 
sion, initiating the control operator trans- 
action program, and setting the LU definition 
and session limits. The LU then initiates 
programs and activates sessions in response 
to further operator, transaction program, or 
partner-LU actions. 


To shut donun the LU, the steps are reversed; 
but some can be omitted. The minimum steps 
to terminate communications include resetting 
the session limits and deactivating the CP-LU 
session. 


LU PROCESS CREATION AND TERMINATION 


Figure 2-33 on page 2-47 shows the process 
creation and termination hierarchy for the 
LU. 


First, the PU in the node creates two dynamic 
processes, RM and LNS. These processes con- 
tinue running thereafter. 


~  RCB F connects it to remote LU W via 
session K with wmode name U. 


-~  RCB G connects it to remote LU Y via 
session P with mode name V. 


° LU W has tno free sessions, M and N, each 
with mode name L. 


® Remote LU X has a single mode name with 
no active sessions. 


e No active TP instances exists for trans- 
action program 3. 


e Two active TP instances exist for trans- 
action program 4: TPs C and D. 


® Two conversations 6 and H exist with 
remote LU Y, each using a different mode 
name. 


® Two conversations I and J use separate 
sessions R and T, both with mode name Z. 


RESOURCE RELATIONSHIPS IN A DISTRIBUTED 
TRANSACTION 


In contrast to Figure 2-31, which illustrates 
the data structures for several transactions 
from the perspective of a single LU, Fig- 
ure 2-32 on page 2-46 illustrates the 
relationships among data structures at 
several LUs from the perspective of a single 
distributed transaction. In this case, the 
paired half-sessions connect LUs, and the 
paired conversation resources, represented by 
RCBs,» connect transaction program instances. 


The PU creates the CP-LU half-session when it 
receives ACTLU session-control RU from the CP 
(see "CP-LU Session Activation"). 


The TP and HS processes are discussed in 
“Rurming State” on page 2-47. 


CP-LU SESSION ACTIVATION 


The CP in the network (the PNCP or the SSCP) 
activates the CP-LU session for the LU by 
sending ACTLU, to which LNS responds, if 
ready, with +RSP(ACTLU). This session acti- 
vation is required prior to any LU-LU session 
initiation or termination. 


When the CP determines that no further ses- 
Sion initiation or termination activity is 
required, it deactivates the CP-LU session by 
sending DACTLU to the LU. 


If the CP-LU session is interrupted because 
of session outage, the CP attempts to reacti- 
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LEGEND: 


Association of a process with its data structures 
Beane’ Conversation (connection between transaction program instances [TPs]) 


====== Session (connection between LUs ) 
TPGM: Transaction program data structure (represents transaction program code) 
~RCB: Resource control block (represents a conversation) 
TP: Transaction program process instance 
iS: Half—session process instance 
Figure 2-32. Data Structure Relationships among LUs for a Distributed Transaction (Example) 
vate it. This need not interrupt normal CONTROL-OPERATOR ACTIONS 
LU-LU session traffic. 
| The control operator specifies the LU defi- 
CONTROL-OPERATOR TRANSACTION PROGRAM INITI- nition describing the LU-accessed network 
ATION resources: the control points, transaction 
programs, partner LUs, and modes. (An imple- 
mentation might provide this function without 
RM creates a PS process and initiates the requiring explicit operator interaction, 
control-operator TP. e.g.» the LU definition might be specified at 
system-definition time. )} 
The operator initializes session limits with 
the partner LUs by issuing the INITIAL- 
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Figure 2-33. 


IZE_SESSION_LIMIT verb for the relevant mode 
names. For parallel-session mode names, this 
verb activates an LU-LU session using the 
SNA-defined mode name SNASVCMG (if not 
already active) and establishes. mutually 
agreeable session limits for other mode names 
by exchanging CNOS GDS variables on that ses- 
Sion. This verb optionally causes activation 
of a predetermined number of sessions for the 
Specified mode name. 


When sessions are to be deactivated, the con- 
trol operator issues RESET_SESSION_LIMIT for 
the mode name. For a parallel-session con- 
nection, this causes another CNOS GDS vari- 
able exchange to elicit the partner LU's 
cooperation in the session shutdown. In any 
case, this verb causes the LU to eventually 
cease initiating new transaction programs and 
activating new sessions (drain). As sessions 
become unused, RM and LNS deactivate them. 


The LU initiates no further actions to shut 
down the LU. Any further actions are at the 
initiative of the CP or the PU. 


Transaction 
Program / 
Presentation 
Services 
Process 


LU-LU 
Half~—Session 
Process 


LU Process Creation and Termination Hierarchy 


RUNNING STATE 


Once the CP-LU session has been activated and 
the LU-LU session limits have been set, the 
LU is ready to process transactions. 


RM creates a transaction-program process when 
it receives an Attach or an initial TP invo- 
cation request; it destroys that process when 
PS indicates that the TP has completed and 
all its conversations have been deallocated. 


Either RM or the partner LU can request ses- 
sion activation; in either case, LNS performs 
the relevant processing. LNS creates an HS 
process for an LU-LU session and connects it 
to a path control instance whenever it sends 
or receives BIND. LNS destroys that process 
when it has sent or received a positive 
response to UNBIND, has’ disconnected the 
half-session from path control (by sending 
PS _HS_DISCONNECT), and has notified the CP 
that the session is ended (by sending 
SESSEND }. 
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EXAMPLE 7 | the local and remote LUs, respectively, for 

| an LU shutdown sequence. ‘Chapter 5.4. Pres- 

| - entation Services--Control-Operator Verbs" 

Figure 2-36 on page 2-54 and Figure 2-37 on describes LU startup and shutdown in more 
page 2-55 illustrate typical interactions at detail. 
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PROTOCOL BOUNDARY SUMMARY 


This section lists the external message units 
and internal records exchanged by LU compo- 
nents. For full descriptions of these struc- 
tures, see "Appendix A. Node Data Structures" 
in Appendix A 


EXTERNAL PROTOCOL BOUNDARY VERBS AND MESSAGE 
UNITS 


PS-TP Protocol Boundary: Transaction Program 
Verbs 


TRANSACTION_PGM_VERB 
Basic-Conversation Verb Variants 


ALLOCATE 
CONFIRM 
CONFIRMED 
DEALLOCATE 

FLUSH 
GET_ATTRIBUTES 
GET_TYPE 
POST_ON_RECEIPT 
PREPARE_TN_PECEIVE 
RECTIVE_AND_WAIT 
REQUEST_TO_SEND 
SEND_DATA 
SEND_ERROR 

TEST 

WAIT 


Mapped-Conversation Verb Variants 


MC_ALLOCATE 
MC_CONFIRM 
MC_CONFIRMED 
MC_DEALLOCATE 
MC_FLUSH 
MC_GET_ATTRIBUTES 
MC_POST_ON_RECEIPT 
MC_PREPARE_TO_RECEIVE 
MC_RECEIVE_AND_WAIT 
MC_REQUEST_TO_SEND 
MC_SEND_DATA 
MC_SEND_ERROR 
MC_TEST 


Control-Operator Verb Variants 


ACTIVATE_SESSION 
CHANGE_SESSION_LIMIT 
DEACTIVATE_SESSION 
INITIALIZE_SESSION_LIMIT 
PROCESS_SESSION_LIMIT 
RESET_SESSION_LIMIT 


LNS-PU Protocol Boundary 


LNS_TO_NNM_RECORD 
ACTLU_RSP_SEND_RECORD 
BIND_RQ_SEND_RECORD 
BIND_RSP_SEND_RECORD 
DACTLU_RSP_SEND_RECORD 


HIERARCHICAL_RESET_RSP 
PC_CONNECT 
PC_HS_CONNECT 
PC_HS_DISCONNECT 
SESSION_ROUTE_INOP_RSP 
UNBIND_RQ_SEND_RECORD 
UNBIND_RSP_SEND_RECORD 


NNM_TO_LNS_RECORD 


ACTLU_RQ_RCV_RECORD 
BIND_RQ_RCV_RECORD 
BIND_RSP_RCV_RECORD 
DACTLU_RQ_RCV_RECORD 
HIERARCHICAL_RESET 
PC_CONNECT_RSP 
SESSION_ROUTE_INOP 
UNBIND_RQ_RCV_RECORD 
UNBIND_RSP_RCV_RECORD 


HS-PC Protocol Boundary 


PC_TO_HS_RECORD 
HS_70_PL_RECORD 


INTER-COMPONENT STRUCTURES 


PS-HS Protocol Boundary 


PS_TO_HS_RECORD 


Variants 
CONFIRMED 
REQUEST_TO_SEND 
SEND_DATA_RECORD 
SEND_ERROR 


HS_TO_PS_RECORD 


CONFIRMED 
RECEIVE _DATA 

RECEIVE _ERROR 
REQUEST_TO_SEND 
RSP_TO_REQUEST_TO_SEND 


PS-RM Protocol Boundary 


PS_TO_RM_RECORD 


ALLOCATE_RCB 
CHANGE_SESSIONS 
DEALLOCATE_RCB 
GET_SESSION 
RM_ACTIVATE_SESSION 
RM_DEACTIVATE_SESSION 
TERMINATE_PS 
UNBIND_PROTOCOL_ERROR 


RM_TO_PS_RECORD 


ATTACH_RECEIVED 
CONVERSATION_FAILURE 
RCB_ALLOCATED 
RCB_DEALLOCATED 
RM_SESSION_ACTIVATED 
SESSION_ALLOCATED 
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RM-HS Protocol Boundary 


RM_TO_HS_RECORD 
BID_RSP 
BID_WITH_ATTACH 
BID_WITHOUT_ATTACH 
BIS_REPLY _ 
BIS_RQ 
HS_PS_CONNECTED 
RTR_RQ 
RTR_RSP 
YIELD. SESSION 
ENCIPHERED_RD2 


HS_TO_RM_RECORD 
ATTACH_HEADER 
BID 
BID_RSP 
BIS_RQ 
BIS_REPLY 
FREE_SESSION 
RTR_RQ 
RTR_RSP 
SECURITY_HEADER 


COMPONENT INTERACTIONS AND FLOW SEQUENCES 
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The following figures illustrate both the 
internal-protocol-boundary flow sequences 
among LU components and the external flows 
between tuo LUs that result from 
basic-conversation verb issuances. 


Each sequence is illustrated by a pair of 
figures on facing pages. Each separate fig- 
ure represents the complete flow as seen by a 
single LU. The figure labeled local LU 
represents the LU that initiates the sequence 
being illustrated; the figure labeled remote 
LU represents the partner LU. For cases 
illustrating a race between two LUs, the LUs 
are distinguished as first speaker and 
bidder. The flows through the path control 
network are shown in the column nearest the 
center margin, and are replicated in each 
figures numerals in parentheses correlate 
corresponding flows in the facing figures. 
When flows cross in the path-control network, 
the crossing is illustrated on the sending 
side of the delayed flow. 


NOTATION 


For the interpretation of labels on the 
arrows, see the following: (which, in some 


RN-LNS Protocol Boundary 


RM_TO_LNS_RECORD 
ACTIVATE_SESSION 
DEACTIVATE_SESSION 


LNS_TO_RM_RECORD 
ACTIVATE_SESSION_RSP 
CTERM_DEACTIVATE_SESSION 
SESSION_ACTIVATED 
SESSION_DEACTIVATED 


LNS-HS Protocol Boundary 


LNS_TO_HS_RECORD 
HS_SEND_RECORD 
INIT_HS 


HS_TO_LNS_RECORD 
ABORT_HS 
HS_RCV_RECORD 
INIT_HS_RSP 


ea 


cases have been abbreviated) 


® For verb and = verb-parameter names 
(TP-PS), SNA Transaction Programmer's 
Reference Manual for LU Type 6.2 


® For protocol-boundary records and message 
units (TP-PS, PS-RM, RN-LNS), "Protocol 
Boundary Summary" on page 2-49 


® For RU names (LNS-LNS, HS-HS), "Appendix 
E. Request/Response Unit (RU) Formats" 


® For RH indicators (LNS-LNS, HS-HS), "Ap- 
pendix D. RH Formats" 


The following abbreviations for chaining 
indicators are also used: 


- FIC (first in chain) = (BC,-~EC) 
—- MIC (middle in chain) = (-BC,-EC) 
- LIC (last in chain) = (-BC, EC) 
- OIC fonly in chain) = (BC, EC) 

¢ For data elements of RUs (LUNS-LNS, 


HS-HS), “Appendix H. FM Header and LU 
Services Commands" 
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TP PS __RM LNS HSCFSP) (to partner LU) 


ALLOC(when allocated) ALLOCATE_RCB 


RCB_ALLOCATED( OK) | 
o< 


GET_SESSION(NO_ATTACH) ACTIVATE_SESSION 2 BIND2 


-> (a) 
+RSP( BIND )2 soit 
1 .——_ _—_-— __________—____ ——— (b>) 


[ENIT_HS 
20 > 
ACTIVATE_ INIT_ | crvs 
SESSION_ HS = -> (ce) 


RC=0K SESSION_ALLOCATED(OK) RSP(+) RSP(+) +RSP(CRV)2 


0 Se eeteeeeereeeeeteeememnneneenienemneeaininn © bsteeenieniemnemimmmmanmmnemmmenmmemmiamnmenmal © os nammmnmnmmmmmmenaeenimmmamnmememmmaanees © Sammemmnmmmemene © a (d)} 


ENCIPHERED_RD2* BC,~EC,RQE1,-~BB,FMH—-124 


°———— ooo eos Ce) 


HS_PS_CONNECTED 
SEND_DATA SEND_DATACALLOC,FMH,DATA,NOT_END_OF_DATA) “BC, RQE1,FMH-5,DATA 


cic lace ca 


RC=OK | 
o< 


SEND_DATA SEND_DATA(DATA,NOT_END_OF_DATA) os : RQE1,DATA 


RC=0K | 
o< 


SEND_DATA(DATA, | . 
RECEIVE_AND_WAIT PREPARE_TO_RCV_FLUSH) EC,RQE1,CD,DATA 


eee eee OO eee > (3) 


-RC=OK,DATA_COMPLETE RCVD_DATACDATA,DEALLOCATE_FLUSH) BC,EC,RQE1,CEB,DATA 


|RECEIVE_AND_WAIT FREE_SESSION | 
>o o< 


RC=DEALLOCATE_NORMAL 
Pecerey Oot Sater 


(4) 


o< 


[DEALLOCATE LOCAL DEALLOCATE_RCB 
D Cpr eer PO} 
RC=0K RCB_DEALLOCATED | 
Qo nS 


NOTES: 

Session-activation flows to PU, CP, and path control have been omitted; 
see "Chapter 4. LU Network Services" for details. 
BIND/RSP(BIND) flows through the PU (not shown). 
CRV/RSP(CRV) flows only when session-level cryptography is being used. 
Flows only when LU-LU verification is being used. 


2 ah 


Figure 2-34. Complete Conversation Example--I cua. LU 
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(to partner LU) — (Bidder HS LNS RM PS TP 


BIND@ i 
(a ) ween a A AS ASSES OS ASS RSENSES GAS 


+RSP( BIND )? | 
(b) < 1 
INIT_HS 
oe 
crv? 
(ic) ————_—— 39 
+RSP(CRV)® | INIT_ 
(d) < HS 


| RSP(+) SESSION_ACTIVATED 
0 6 aS) 


BC,-EC,RQE1,-BB,FMH-124 SECURITY_HEADER® 
(oo ——— 


“BC ,RQE1,FMH-5,DATA BID 
(1) 0 —— — —— — — 0 


BID_RSP( POS) | 
o< 


ATTACH_HEADER ATTACH 
terete JF peorerteenaeemeseeennteeneeeneernnmmneranuaane 2 
RECEIVE AND_WAIT | 
o< 


HS_PS_ CONNECTED | 
o< 


RQE1,DATA RCVD_DATA( DATA,NOT_END_OF_DATA) 


RCVD_DATA(DATA, | 
EC,RQE1,CD,DATA PREPARE_TO_RCV_FLUSH ) 


SEND_DATA(DATA,NOT_END_OF_DATA) 
o< 


BC,EC,RQE1,CEB,DATA SEND_DATA(DATA,DEALLOCATE_FLUSH ) 
arene OK 


RC-OK, 


WHAT_RCVD=DATA_*COMPLETE 
(me 0 


RECEIVE _AND_WAIT | 
o< 


RC=OK; 


WHAT_RCVD=DATA_COMPLETE 
CB) i yeti > Cpe >) 


RECEIVE AND_WAIT 
o< 


RC=-OK, 
WHAT_RCVD=SEND 
>0 
SEND_DATA | 
o< 
| RC=OK 
70 


| RCB_DEALLOCATED RC=OK 


OT as 


FREE_SESSION 
>o 


NOTES: 
Session-activation flows to PU, CP, and path control have been omitted. 
2 BIND/RSP(BIND) flows through the PU (not shown). 
> CRV/RSP(CRV) flows only when session-level cryptography is being used. 
Flows only when LU-LU verification is being used. 


Figure 2-35. Complete Conversation Example--Remote LU 
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DEALLOCATE FLUSH | 
o<~ 

DEALLOCATE_RCB | 
o< 


2-85 


CCP2 TP __ PS ___ RM | __LNS _HSCFSP) (to partner LU) 


RESET_SESSION_LIMIT? 
lprrore cere enerncnconconmememremmasimnrementcie JF EY 


(if parallel session, CNOS exchange occurs here) _ 


CHANGE_SESSIONS? 
—__—_—— 0 
r 
(drain action)® 
BIS_RQ BIS,RQ,BC,EC,RQE1,-BB,-CEB- 
OC) 
Repeat for a 
each session  < _BIS_REPLY BIS,RQ,BC,EC,RQE3,~BB, “CEB 
for the. oti rrr Cee ( D ) 
specified | 
mode name. — locactavare_sessr0n 3 UNBIND> | 
| > > (8) 


+RSP( UNBIND )> | 
9 cee eee eee (by) 


NOTES: 


~ 


For specific-session deactivation, substitute DEACTIVATE_SESSION and eliminate the CNOS exchange. 
For SPEC) Pe-sesaien deactivation, substitute RM_ DEACTIVATE ~SESSION and eliminate the drain action 


Drain action: wait until no bed tocar requests siiguea by drain state are pending, 

then wait until session is in between-brackets state, i.e., +RSP(CEB) is sent or received. 
Session-deactivation flows to PU and CP have been omitted. 

UNBIND/RSP(UNBIND) flows through the PU (not shown) 


Figure 2-36. Session Deactivation--Local LU 
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(to partner LU) (Bidder )HS LNS RM PS CNOS TP 


(if parallel session, CNOS exchange occurs here) 


CME) a ee >o 
BIS,RQ,BC,EC,RQE1 ,-BB,-CEB BIS_RQ 
nin na Freee eremnesenterrrirernns PED 
(drain action)*® 
BIS,RQ,BC,EC,RQE3,-BB,-CEB BIS_REPLY 
C220 <————————— nn OOO "O repeat for 
> each session 
UNBIND®? SESSION_DEACTIVATED in mode 
(a)  ———————————————— — 0 
+RSP( UNBIND )> | 
(b) < 4 
NOTES: 


> Drain action: wait until no allocation requests allowed by drain state are pending, 
then wait until session is in between-brackets state, i.e.» +RSP(CEB) is sent or received. 
Session-activation flows to PU and CP have been omitted. 

5 UNBIND/RSP(UNBIND) flows through the PU (not shown). 


Figure 2-37. Session Deactivation--Remote LU 
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TP : PS | __. HS(FSP) (to partner LU) 


ALLOC(when allocated) ALLOCATE_RCB 


RCB_ALLOCATED( OK) | 
o< 


GET_SESSION( NO ATTACH) HS_PS_CONNECTED 
| Serene 


RC=0K SESSION_ALLOCATED( OK )| 
Oren CPT 
| SEND_DATA 
>0 


RC=0K | 
o< 


| CONFIRM SEND_DATA( ALLOC,, FMH , DATA, CONFIRM) OIC,BB,RQD2|3,ATTACH data 
> 1D 
RC=0K CONFIRMED +RSP 
> ) ee ° “O< —— (2) 


Figure 2-38. ALLOCATE (when allocated), CONFIRM (by First Speaker) --Local LU 
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tner HS( Bidder ) RM PS TP 


OIC, BB, RQD2|3, ATTACH, data BID 
(1) a 0 


BID_RSP( POS) ] 
o< 
ATTACH_HEADER ATTACH 


HS_PS_CONNECTED | RECEIVE_AND_WAIT | 
ox o< 


Q 
RC=OK, | 
| RCVO_DATA( DATA, CONFIRM) WHAT_RCVD=DATA_*®COMPLETE 


RECEIVE_AND_ WAIT 
o< 


RC=OK, 
WHAT_RCVD=CONF IRM 
70 


#RSP CONFIRMED CONFIRMED | 
(2) en ea A he 


| RC=NONE 
>o 


Figure 2-39. ALLOCATE (when allocated), CONFIRM (by First Speaker) --Remote LU 
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(to partner LU) 
ALLOC( delayed) ALLOCATE_RCB 


RC=OK RCB_ALLOCATED( OK ) 
9. he 
| SEND_DATA 
20 
RC=O0K | 
o< 


| CONFIRM GET_SESSION( ATTACH) BID_WITH_ATTACH  OIC,BB,RQD2]3,ATTACH, data 


> parece aeeenenancmnmntennernennanan } fpnmetuenemnnenemeananerneennentan 3 (Ypnnenrssemmnerenmenennnanenmsnansrmanemnrencemreranarmennaemen 3 ( |} 


SESSION_ALLOCATED( OK )| 
| _HS_PS_CONNECTED 


->0 


RC=OK = =—_ CONFIRMED _ oe RSP 
Sop eee ce Fae ae I ee TES 


Figure 2-40. ALLOCATE (delayed), CONFIRM (by First Speaker) --Local LU 
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tner_LU HS( Bidder } RM PS TP 


OIC,BB,RQD2|3,ATTACH, data BID 
Drennan Ch 


BID_RSP( POS) | 
o< 
| ATTACH_HEADER ATTACH 
D> (Cprentrnerter rece omeneronuninntamnmaaremematinens > (fponencermereraimnnnernmarermarsensecememenemaness PE 


HS_PS_CONNECTED | RECEIVE_AND_WAIT | 
o< o< 


RC=OK, 
| RCVD_DATA( DATA, CONFIRM) WHAT_RCVD=DATA_*COMPLETE 
DT 0 ney 9 


RECEIVE_AND_WAIT | 
o< 


RC=OK; 
WHAT_RCVD=CONF IRM 
>O 
+RSP CONFIRMED CONFIRMED | 
0 5, nd ob de 
| RC=NONE 
>o 


Figure 2-41. ALLOCATE (delayed), CONFIRM (by First Speaker) --Remote LU 


(1) 


Chapter 2. Overview of the LU = 2-59 


TP PS RM HSI FSP) 


(to partner LU) 
ALLOC( delayed) ALLOCATE_RCB | 


RC= RCB_ALLOCATED( OK) | 
TY 4 
| SEND_DATA | 
>0 
RC=0K | 
o< 
| RCV_ANO_WAIT GET_SESSCATTACH ) BID_WITH_ATTACH OIC,BB,RQE1,CD,ATTACH, data 


Ss ec cae PS 


SESSION_ALLOCATED( 0K }| 
o< | 
| HS_PS_CONNECTED 


0 


RCVD_ERROR 


-RSP( 0846 ) 
9 ener tectemnntnenc enn eotonesmnncntinmnimnantnnaimssmesrtnernueramcecsviscnanrmen £3 (2) 
RC=PRUG_ERROR_ RCVD_DATACFMH, DATA, | 
PURGING —S——”—CO@PREPARE_ TO_RCV_FLUSH) OIC, RQE!,CD,FMH7 


Figure 2~42. ALLOCATE (delayed), RECEIVE_AND_WAIT (by First Speaker) --Local LU 
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(to partner LU) HS( Bidder ) RM PS TP 


OIC,BB,RQE1,CD, ATTACH, data BID 
CD 


BID_RSP( POS) | 
o< 
| ATTACH_HEADER ATTACH 
D> prec ntemercnnerrecamanamerenamemmisnme [> (pummnrncnaminssnrmntsnminremansinsstteeemeneree + CY 


HS_PS_CONNECTED | RECEIVE_AND_WAIT | 
o< o< 


RCVD_DATA( DATA, RC=OK, 
PREPARE_TO_RCV_FLUSH) | WHAT_RCVD=DATA_*COMPLETE 
> rere cnnettoenirnematimme EY 
—RSP( 0846) SEND_ERROR SEND_ERROR | 
C2) ec a 
| RC=0K 
SEND_DATA(FMH,DATA, >0 
OIC,RQE1,CD,FMH7 PREPARE_TO_RCV_FLUSH) RECEIVE_AND_WAIT | 
C3) << —sa§EeeeeEESeESSSSSSSSSSSssi—7—“*< . 


Figure 2-43. ALLOCATE (delayed), RECEIVE_AND_WAIT (by First Speaker) --Remote LU 
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TP __PS RM | HS(Bidder) (to partner LU) 
ALLOC(when allocated) ALLOCATE_RCB 


rom > ° eed”) 
RCB_ ALLOCATED(0K) | 
o< 
GET_SESS(NO_ATTACH) BIO_WITHOUT_ATTACH LUSTAT,BB,RQD1 
Sa a eS (1) 
RC=0K SESSION_ALLOCATED( OK ) BID_RSP( POS) +RSP 
o<—— o<- OS rere crc ererenrernimnemen £9 C rare sereniemerenemennrenrenscercemmesermeermrmmccmmermcmas  ( 9 } 


| SEND_DATA | ! HS_PS_ CONNECTED 
. >o none DC) 
RC=0K | | 
o< , SEND_DATA( FMH DATA, 
| RCV_AND_WATT PREPARE_TO_RCV_FLUSH) OIC ,RQE1,CD, ATTACH, data 


DD perenne stem ecentncanrmieme een thneneRNE PASI STEGER (Preteen ttt ene AEE TATED oP (3) ; 


Figure 2-44. ALLOCATE (when allocated), RECEIVE_AND_WAIT (by Bidder) --Local LU 
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(to partner LU) 


LUSTAT,BB,RQD1 
+RSP 


OIC,RQE1,CD, ATTACH, data 
(3) 


Figure 2-45. 


HSC FSP.) RM PS TP 
~ BID 
-—————$$— 9 


BID_RSP(PNS 


o< 


ATTACH_HEADER ATTACH 


Fg re) 
HS_PS_CONNECTED | RECEIVE_AND_WAIT | 
o< o< 


RCVD_DATA(DATA, RC=OK, 
PREPARE_TO_RCV_FLUSH ) WHAT_RCVD=DATA_*COMPLETE 
eee 5G 


RECEIVE AND_WAIT | 
o< 


RC-OK, 
WHAT_RCVD=SEND 
>O 


ALLOCATE (when allocated), RECEIVE_AND_WAIT (by Bidder) --Remote LU 


- Chapter 2. Overview of the LU 


2-63 


TP S ___RM ________ HS (Bidder) | (to partner LU) 
ALLOC( delayed) ALLOCATE_RCB | 


RC=0K RCB_ALLOCATED(OK) | 
0 nee Le 
| SEND_DATA | 
>o. 
RC=0K | 
o< 


| CONFIRM GET_SESSION( ATTACH) BID_WITH_ATTACH  OIC,BB,RQD2|3,ATTACH, data 


SESSION_ALLOCATED( OK ) BID_RSP( POS ) +RSP , 
1 a eee (2) 


| HS_PS_CONNECTED 
RC=0K CONFIRMED _ | 
6——— 9 ¢ 


Figure 2-46. ALLOCATE (delayed), CONFIRM (by Bidder) --Local LU 
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~ 41) 


OIC,BB,RQD2|3,ATTACH, data BID 
Dp rere ED 


BID_RSP( POS) 
o< 


| ATTACH_HEADER ATTACH 
D> perenne ncreenaromeenerceimcmememuneemtee 3} ipacarennennsmateaneeeecnemaevacmmmmmeane > EP 


HS_PS_CONNECTED| _RECEIVE_AND_WAIT | 
o< o< 


RC=OK, 
| RCVD_DATA(DATA,CONF IRM) WHAT_RCVD=DATA_*COMPLETE 
D (pornos PED 


RECEIVE _AND_WAIT | 
o< 


RC=OK, 
WHAT_RCVD=CONFIRM 
| $6 


| +RSP CONFIRMED CONFIRMED | 


| RC=NONE 
; . >0 


Figure 2-47. ALLOCATE (delayed), CONFIRM (by Bidder) ~-Rewote LU 
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ALLOC( delayed) ALLOCATE_RCB 


RC=0K RCB_ALLOCATED( 0K) | 
Se Le 
| SEND_DATA 

>o 


RC=0K 
o< 


| RCV_AND_WAIT GET_SESSION( ATTACH ) BID_WITH_ATTACH OIC,BB,RQE1,CD,ATTACH, data =. > 


- SESSION_ALLOCATED(0K) ~ BIDLRSP(POS) =e FIC,data 
| HS_PS_CONNECTED 
RC=OK, WHAT_RCVD= | >0 


DATA_*COMPLETE RCVD_DATA(DATA,NOT_END_OF_DATA) 
CO) ec erereenerrrnrrncereemeees (pS, 


Figure 2-48. ALLOCATE (delayed), RECEIVE_ANO_WAIT (by Bidder) --Local LU 


2-66 SNA Format and Protocol Reference Manual for LU Type 6.2 


(to partner LU): ©) 


HS( FSP) RM PS | TP 


OIC, BB,RQE1,CD,ATTACH data BID 


BID_RSP( POS) | 
o<— 
| ATTACH_HEADER ATTACH 


HS_PS_CONNECTED | | RECEIVE_AND_WAIT| 
o< o< 


RCVD_DATA(DATA, RC=0K; 
PREPARE_TO_RCV_FLUSH WHAT_RCVD=DATA_*COMPLETE 


RECEIVE_AND_WAIT | 
o< 


RC=OK, 
WHAT_RCVD=SEND 
20 
FIC, data SEND_DATA(DATA,NOT_END_OF_ DATA) SEND_DATA 
C2) Cine eeertennemememeeenye ou ONE | 


| RC=OK 
>0 


(1) 


Figure 2-49. ALLOCATE (delayed), RECEIVE_AND_WAIT (by Bidder) --Remote LU 
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TP | PS RM __HS( Bidder) (to partner LU) | 


ALLOC( delayed) ALLOCATE_RCB 
7 


RC=0K RCB_ALLOCATED(OK ) | 
p< rent ereresceeacmeeemomnemannanctenannnae 9 
| SEND_DATA 
>o 
RC=0K | 
o< 


| CONFIRM GET_SESSION( ATTACH) BID_WITH_ATTACH OIC,BB,RQD2]3,ATTACH, data 


SESSION_ALLOCATED(OK)  #BID_RSP( POS) —~RSP( 0846 ) 


o< rn QC enn ( 2) 


| HS_PS_CONNECTED 
>o 
RCVD_ERROR | 
o< 


RCVD_DATACFMH , DATA, | 
RC=ALLOCATION_ERROR DEALLOCATE_FLUSH) | OIC,CEB,RQE1,FMH7 
reer enn Cece ncnnenenrneerneeeeeennsenenssenegeememans (7) 


[DEALLOCATE_LOCAL DEALLOCATE_RCB FREE_SESSION | 
> Q———— 0K 
RC=0K RCB_DEALLOCATED 
0s onesie cae 


Figure 2-50. ALLOCATE (delayed), CONFIRM (by Bidder), Attach Error --Local LU > 


(3) 
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(to partner LU) 


(1) 


~RSP( 0846 ) 
(2) < 


OIC,CEB,RQE1,FMH7 
(3) < 


Figure 2-51. 


OIC,BB,RQD2|3,ATTACH, data 


HSCFSP) RM PS 


BID 
DO enc cetctrmeenccnen ED 


BID_RSP( POS) | 
o< 


ATTACH( ALLOCATION 
ATTACH_HEADER ERROR ) 
2 mee > CD 


HS_PS_CONNECTED | 
o< 


RCVD_DATA( DATA, CONFIRM) 


SEND_ERROR 
o< 


SEND_DATACFMH,DATA, 
DEALLOCATE_FLUSH } 
o< 


| FREE_SESSION DEALLOCATE_RCB | 
>o< 
| RCB_DEALLOCATED 
>o 


Chapter 2. 


TP 


ALLOCATE (delayed), CONFIRM (by Bidder), Attach Error --Remote LU 


Overview of the LU 
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TP PS _—saRM _HS(FSP) (to partner LU) 
ALLOCATE( immediate) ALLOCATE_RCB( immediate) 


ricco OG eins eee a“ 
FSP session available 


RC=0K RCB_ALLOCATED( OK) | a 
06 ot 
| | HS_PS_CONNECTED 
>0 


® 
e 
@ 


[The flow continues as in the ALLOCATE(when allocated) case. ] 


Figure 2-52. ALLOCATE (immediate), Successful --Local LU 
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(to partner LU) | a ;; Le -.- ike ere! I 


(no activity at remote LU) 


from here on just like ALLOCATE(mhen allocated) 
Figure 2-53. ALLOCATE (immediate), Successful --Remote LU 
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TP 


PS. RM : HS 


ALLOCATE(Cimmediate) ALLOCATE_RCB( immediate) 


RC= 
o< 


(no first—speaker 
session available) 


| RCB_ALLOCATED 
UNSUCCESSFUL (unsuccessful ) 


Figure 2-54. ALLOCATE (immediate), Unsuccessful --Local LU 
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(to partner LU) 


6 7 
% a 


(to partner LU) H R P | p 


(no activity at remote LU) 


Figure 2-55. ALLOCATE (immediate), Unsuccessful --Remote LU 
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TPNCA) _PS(A) RM CS (Bidder) (to partner LU) 


ALLOC( delayed) _ ALLOCATE_RCB~ 
—— 


RC=0OK RCB_ALLOCATED(OK) | 
OK et 
SEND_DATA 
>o 
RC=0OK | 
o< 


| CONFIRM GET_SESSION(ATTACH) BID_WITH_ATTACH  OIC,BB,RQD2|3,ATTACH, data 
SS, a \, i 
3 BID —OIC,BB,RQE1,CD, ATTACH, data 


°° > SE (1) 


TPN(B) PS(B) 7 | BID_RSP(POS) 
Se ee | >o 
ATTACH ATTACH_HEADER | 
ox< nS 
| HS_PS_CONNECTED 
>© 


RECEIVE_AND_WAIT 
>o 


RC=O0K »WHAT_RCVD= RCVD_DATA(DATA, 
DATA_*COMPLETE PREPARE_TO_RCV_FLUSH ) 
Cen (VC 


[RECEIVE_ANO_WAIT 
>o 


RC=OK ,WHAT_RCVD= 
SEND 
o< 


SEND_DATA SEND_DATA(DATA,NOT_END_OF_DATA) 
1 © seemed ©) 


RC=0K enqueued : > (2) 
o< BID_RSP( NEG) ~RSP( 0813) 


0< ——K (3) 
etc. try another session | 
or enqueue dequeue 


| FIC,data 
, . > (4) 


Figure 2-56. ALLOCATE (delayed) Race, Bracket Rejected --Bidder LU 
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(to partner LU) HSCFSP) RM PS TP 


ALLOCATE_RCB ALLOC( delayed) 
$$$ 9) 


| RCB_ALLOCATED(OK) RC=OK 
DT 6 somnneuiemnnmmmeemmmannmammmmaammmmmenmna ©) 
SEND_DATA | 
o< 
| RC=OK 
>o 


OIC,BB,RQE1,CO,ATTACH,data BID_WITH_ATTACH GET_SESS( ATTACH) RECEIVE_AND_WAIT 
Cr rr 6 renner) C 


| SESSION_ALLOCATEDCOK ) 
20 
HS_PS_CONNECTED | 
o< 


OIC,BB,RQD2|3,ATTACH, data BID 
C2 —— 0 


—-RSP( 0813) BID _RSPCNEG) | 
(3) <8 
RC=OK;, 


FIC,data RCVD_DATA(DATA,NOT_END_OF_DATA) WHAT_RCVD=DATA_*®COMPLETE 
fname 6 RR 6 es) 


Figure 2-57. ALLOCATE (delayed) Race, Bracket Rejected --First Speaker LU 
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TPN(A) SCA RM CS (Bidder) (to partner LU) 


ALLOC(delayed) © ~— ALLOCATE_RCB 
—————— 7? 0 


RC=0K RCB_ALLOCATED(OK ) | 
6 ee he 
| SEND_DATA 
20 
RC=OK | 
o< 


| CONFIRM GET_SESSION(ATTACH) BID_WITH_ATTACH  OIC,BB,RQD2|3,ATTACH,data 
ee ee Oe = ; | Pace _ 
BID OTC, BB, CEB,RQE1,ATTACH, data 


TPN(B) PS(B) | BID_RSP( POS) 
| 7 = 
ATTACH ATTACH_HEADER | | 
FO Sy. (4 
HS_PS_CONNECTED 
| . ef 


RECEIVE_AND_WAIT 
>o 
RC=OK »WHAT_RCVD= RCVD_DATA( DATA, 
DATA_*COMPLETE DEALLOCATE_FLUSH) | 
(9K rere cert eer ersiennrctomrenmetaeaontiin hE . 


[RECEIVE_AND_WAIT  FREE_SESSION | 
>o o< 


RC=DEALLOCATE_ 
NORMAL 
o< 
| DEALLOCATE DEALLOCATE_RCB 
D Qe nnenrnncrcmammin SP FF 
RC=OK | RCB_DEALLOCATED | 
cere OFT 


TPNCA) PS(A) | 
SESSION_ALLOCATED(OK} BID_RSP(POS) — +RSP 
——————o<— , (3) 


————$$——— 96 . 


| HS_PS_CONNECTED 
RC=0K CONFIRMED | 


Figure 2-58. ALLOCATE (delayed) Race, Bracket Accepted ~-Bidder LU 
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(to partner LU) SCFSP RM OD 


ALLOCATE_RCB ALLOC( delayed) 
“ceo kh eke eeeS_oeeS<_0uQ_$e_—__ Oo 


| RCB_ALLOCATED(OK) RC=OK 
De neem SF EF 
SEND_DATA | 
o< 
| RC=0OK 
>o 


OIC,BB,CEB,RQE1,ATTACH,data BID_WITH_ATTACH GET_SESS( ATTACH) DEALLOCATE_FLUSH 
CL —— — —— — 


| SESSION_ALLOCATED(OK) RC=O0K 
>0 
HS_PS_CONNECTED | 
o< 
| FREE_SESSION DEALLOCATE_RCB 
>o< 
| RCB_DEALLOCATED RC=0K 
Qe OO 
OIC,BB,RQD2|3,ATTACH, data BID 
©, eT.) 
BID_RSP( POS) | 
o< 
| ATTACH_HEADER ATTACH 
> Qe ene eens (feces murammremananen aeons ET 


HS_PS_CONNECTED | RECEIVE_AND_WAIT | 
o< o< 


RC=O0K, 
| RCVD_DATA(DATA,CONFIRM) WHAT_RCVD=DATA_*COMPLETE 
ed © 


RECEIVE _DATA 
o< 


RC=O0K ,»WHAT_RCVD= 
CONFIRM 
>Oo 


+RSP CONFIRMED CONFIRMED 
© © 


| RC=NONE 
>o 


Figure 2-59. ALLOCATE (delayed) Race, Bracket Accepted --First Speaker LU 
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5 eR 2 a cn {1 ae eee » E ro (to partner LU) 


chattel aca FLUSH SEND. _DATA(DEALLOCATE. Pinisii ioe atacetnladn sie ee — LIC, CEB,RGEL : 


| FREE_SESSION. SESSION i 
DEALLOCATE_! RCB 


RC=0K | RCB_DEALLOCATED | DEALLOGATED | 
Picks RO sen lcsuneaelaete 


Figure 2-60. DEALLOCATE FLUSH (RQE1) --Local LU 
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(to partner LU) 


LIC,CEB,RQE1 
(1) : 


S . RM P 


RECEIVE_AND_WAIT 
nn meet 
RCVD_DATA( DEALLOCATE_FLUSH ) RC=DEALLOCATE_NORMAL 


FREE_SESSION DEALLOCATE_RCB DEALLOCATE_LOCAL | 
ST ey < 


RCB_DEALLOCATED 


RC=0K 
6 


Figure 2-61. DEALLOCATE FLUSH (RQE1) --Remote LU 
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(to partner LU) 


| (sequence number wrap) 
DEALLOCATE_ FLUSH © ~ SEND_ DATACDEALLOCATE_ FLUSH ) LIC,CEB,R@D1* 


FREE_SESSION . +RSP 
gee 
DEALLOCATE_RCB | 
RC=0K RCB_DEALLOCATED 
9 6 coerce nemntremmrancmanmemn gS, 


NOTES: 
2 RQD1 is required under certain sequence number wrap conditions. 


Figure 2-62. DEALLOCATE FLUSH (R@D1) --Local LU 
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to partner LU) HS. RM | P 7 TP 


RECEIVE_AND_WAIT 


. re) 
LIC,CEB,RQDI RCVD_DATA( DEALLOCATE_FLUSH ) RC=DEALLOCATE_NORMAL 
CD erect neneremnrmemmecin®  (peanneneteeenenn atten ea tetera remnant (perm mewersrnsoneresrssrasemnarrccacaann oP FY 
+RSP | DEALLOCATE_RCB DEALLOCATE_LOCAL | 

(2) < . o< o< 


| FREE_SESSION 7 
>o 
| RCB_DEALLOCATED RC=0K 
> Cpe FEY 


Figure 2-63. DEALLOCATE FLUSH (RQD1) --Remote LU 
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TP ee: eee ee ee, eee eee ae (to partner LU)” 


SEND_DATA SEND_DATA(DATA,NOT_END_OF_DATA)  FIC,data sss tate athe 
° eee UL) 


o< : | 
| DEALLOCATE_FLUSH SEND_DATA(DATA,DEALLOCATE_FLUSH ) LIC,CEB,RQE1 
oe 


FREE SESSION | 
RSP 0846 } 


“oO | oo 
ae (This stray response 
is discarded) - 


‘DEALLOCATE_RCB 


RC=0K 


RCB_DEALLOCATED 
S- 


Figure 2-64. DEALLOCATE FLUSH (RQE1), SEND_ERROR, -RSP Sent --Local’ LU 
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(to partner LU) | eee |; eee Seca een Ueae 


RECEIVE_AND_WAIT 
0 | Seen 
FIC, data RCVD_DATA(DATA,NOT_END_OF_DATA) RC=OK, 
. > 0 WHAT_RCVD= 


| DATA_*COMPLETE 
>o 


(1) 


—RSP( 0846) | SEND_ERROR SEND_ERROR 
Sele o< 
LIC, CEB,RQE1 RCVD_DATA(DATA,DEALLOCATE_FLUSH) | RC=DEALLOCATE_NORMAL 


(3) 


| FREE_SESSION DEALLOCATE_RCB DEALLOCATE_LOCAL | 
>0¢———— 9 ¢ 
| RCB_DEALLOCATED RC=0K 
, Se eG 


Figure 2-65. DEALLOCATE FLUSH (RQE1), SEND_ERROR, -RSP Sent --Remote LU 
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TP . PS RM HS : (to partner LU) 


SEND_DATA SEND_DATA(DATA,NOT_END_OF_DATA) FIC, data 


nr eter eee rtsemtneenemtnttnss Df pinstennnstsonotnnntvaemnnnineesermcemsnetenearnnnsiiensrputnenninveeerenannmimennecemmenci =D jnmmenrsscesmscamecucsronmmnecransmsaromonamaneworronemcmmarnmrsenen 3 ( | } 


RC=0K | 
o< 


| DEALLOCATE_FLUSH SEND_DATA(DATA,DEALLOCATE_FLUSH } LIC,CEB,RQE1 


Se (2) 


FREE_ SESSION | a 
o<— ms 


>0 


ae 


RC=0K RCB_DEALLOCATED 
o<— : 


o< 


Figure 2-66. DEALLOCATE FLUSH (RQE1), SEND_ERROR, -RSP not Sent --Local LU 
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TP 


(to partner LU) HS RM PS 


RECEIVE_AND_WAIT 
——_——oo 0 
FIC, data RCVD_DATA( DATA,NOT_END_OF_DATA) RCENK 
CL) 0 WHAT_RCOVD= 


| DATA_*®COMPLETE 
>o 
LIC,CEB,RQE1 RCVD_DATA(DATA,DEALLOCATE_FLUSH } 


OQ terrence PC) 


| FREE_SESSION SEND_ERROR 
>oO o< 
| RG=DEALLOC_NORMAL 
>o 
DEALLOCATE_RCB DEALLOCATE_LOCAL | 
ae eeeeeerneed © 


| RCB_DEALLOCATED RC=OK 
> HG 


Figure 2-67. DEALLOCATE FLUSH (RQE1), SEND_ERROR, -RSP not Sent --Remote LU 
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TP } __PS | RM == HS 2s (to partner LU) 


DEALLOCATE_CONFIRM SEND_DATA(DEALLOCATE_CONFIRM) EC,CEB,RQD2|3 
ce a aca creer LD 
CONFIRMED | +RSP 


oe o< 
| DEALLOCATE_RCB FPEE_ SESSION | 
~ >o< 


(2) 


RC=0K 
9 eee 


RCB_DEALLOCATED 


Figure 2-68. DEALLOCATE CONFIRM (RQD213) --Local LU 
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(to partner LU) 


EC,CEB,RQC2|3 


+RSP 


HS RM PS TP 


RECEIVE_AND_WAIT 

o<————_________—_5 

RCVD_DATA(DEALLOCATE_CONFIRM) RC=OK,WHAT_RCVD=CONFIRM 
arn nee >> {jponeneeennnsnnsnesnenenenensae: >> €) 


CONFIRMED CONFIRMED | 
arr rr a RE ESSE 
| FREE_SESSION | RC-0K 
>o >0 
RECEIVE_AND_WAIT’ | 
o< 


RC= 
| DEALLOCATE_NORMAL 
20 
DEALLOCATE_RCB DEALLOCATE_LOCAL | 
een 
RCB_DEALLOCATED RC=0K 
D> pre eerencemenarcm DR 


Figure 2-69. DEALLOCATE CONFIRM (RQD2/3) --Remute LU 
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TP pg | RM a HS - (to partner LU) 


- SEND_DATACFMH DATA, oO 
DEALLOCATE_ABEND DEALLOCATE_FLUSH) | — OIC,CEB,RQD1,FMH7( 0864) 
<a i  ) nb ar ae a | 


| DEALLOCATE_RCB FREE_SESSION | +RSP | , 

| >o< OQ 6 nen ( 2 } 
RC=0K RCB_DEALLOCATED | 7 

“08 


Figure 2-70. DEALLOCATE ABEND Issued in SEND, Between-Chain State --Local LU 
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(to partner LU) HS RM PS TP 
RECEIVE _AND_WAIT 
RCVD_DATA(CFMH,DATA; <2 
OIC, CEB ,RQD!1 , FMH7( 0864) DEALLOCATE_FLUSH) RC=DEALLOC_ABEND 


(1) eae CH SSR cS cM RR ERI 


+RSP | DEALLOCATE_RCB = DEALLOCATE_LOCAL | 
(2) < pt i ean 
| RCB_DEALLOCATED RC=OK 
eG 
FREE_SESSION 
>o 


Figure 2-71. DEALLOCATE ABEND Issued in SEND, Between-Chain State --Remote LU 
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(to partner LU) 


SEND_DATA _SEND_DATA(DATA,NOT_END_OF_DATA) FIC, data - 


RC=0K . | 
o< an 


SEND_DATACFMH,DATA, 
— . - DEALLOCATE_FLUSH) 


DEALLOCATE_ABEND 


LIC, CEB,RQD1,FMH7( 0864) 
————— 


~f DEALLOCATE_RCB - FREE SESSION #RSP 

: De nC errr nttnenoreenmteermeens (By 
RC=-0K RCB_DEALLOCATED | = : 

Snr C) 


Figure 2-72. DEALLOCATE ABEND Issued in SEND, In-Chain State --Local LU 
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(to partner LU) HS RM PS TP 


RECEIVE _AND_WAIT 
oS 0 
FIC,data RCVD_DATA(DATA,NOT_END_OF_DATA) RC=0K »NWHAT_RCVD= 
ee ee Oe SQ DATA *XCOMPLETE 
Le > 


RECEIVE_AND_WAIT | 
o< 


RCVD_DATA(FMH,DATA, 
LIC,CEB,RQD1 ,FMH7( 0864) DEALLOCATE_FLUSH) RC=DEALLOCATE_ABEND 
Ua a ct a eG 


+RSP | DEALLOCATE_RCB DEALLOCATE_LOCAL | 
(3) < he 
! RCB_DEALLOCATED RC=OK 
SO eG 


>o 


FREE_SESSION 


Figure 2-73. DEALLOCATE ABEND Issued in SEND, In-Chain State --Remote LU 
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SEND_DATA 
0, 


RC-OK | 
o< . 


FLUSH -SEND_DATA(DATA,NOT_END_OF_DATA) _— FIC, data 
Pen As Nene enero eRe ante TAc Seo + Conse Minin menor teeeerererteeetreeer eee a 


sieiniantenscicentel 


o<- 


-RCVD_ERROR ° _ x ~RSP( 0846 ) 


—=O< (2). 


DEALLOCATE_ABEND | SEND_DATA(FMH,DATA,DEALLOC_FLUSH):». LIC,CEB,R@QD1,FMH7( 0864) 


| DEALLOCATE_RCB. | FREE_SESSION q 
->Oo<——— 


RC=0K | RCB_DEALLOCATEO | : 
Ce . —_ - 


Figure 2-74. DEALLOCATE ABEND Issued in SEND, -RSP Received State --Local LU 
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(to partner LU) HS RM PS TP 


RECEIVE_AND_WAIT 
© 4 eee ° 

RC=OK »WHAT_RCVD= 

FIC,data RCVD_DATA(DATA,NOT_END_OF_DATA) DATA_®COMPLETE 
Ce Fy OG 


—RSP( 0846 ) SEND_ERROR SEND_ERROR 
1-2) <*> nena 
RCVD_DATA(FMH,DATA;, 
LIC,CEB,RQD1,FMH7( 0864) DEALLOCATE_FLUSH ) RC=DEALLOCATE_NORMAL 
© 3 ene 6 * Seen 6 ee) 


| FREE_SESSION DEALLOCATE_RCB DEALLOCATE | 
>ox< o< 
| RCB_DEALLOCATED RC=0K 
0 6 er.) 


NOTE: This TP gets no indication that the DEALLOCATE is of type ABEND 
because everything (including FM headers) is discarded when purging. 


Figure 2-75. DEALLOCATE ABEND Issued in SEND, -RSP Received State --Remote LU 
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SEND_DATA SEND_DATA(DATA,NOT_END_OF_DATA) —s- FIC, data | 
RC=0K | ea aaa 
o< 
| SEND_DATACFMH DATA, , 
DEALLOCATE_ABEND DEALLOCATE_FLUSH) §=»-»-»ss—sLIC, CEB, RQD1,FIH700064) 


> 


| DEALLOCATE_RCB FREE_SESSION = = == ~RSP( 0846 ) 


RC=0K RCB_DEALLOCATED | | Lo ae ae hy 
Sanne VC , , | | 


(3) 


Figure 2-76. DEALLOCATE ABEND Issued in SEND State --Local LU 
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>a 


(to partner LU). | HS RM , , S TP 


RECEIVE_AND_WAIT 
—_—_—_—_—_—_—_—_—PFJ 


FIC, data RCVD_DATA(DATA,NOT_END_OF_DATA) RC=0K »WHAT_RCVD= 
(1) , ys DATA_*COMPLETE 
Geena ieee 


~RSP( 0846 ) SEND_ERROR SEND_ERROR | 
eC 


o< 

RCVD_DATACFMH,DATA, : 
RQD1,FMH7(0864) # }.}3§3§=. DEALLOCATE_FLUSH) =.  RC=DEALLOCATE_NORMAL 
ere 


| FREE_SESSION DEALLOCATE_RCB DEALLOCATE_LOCAL | 
: : — DO en OS 
| RCB_DEALLOCATED RC=0K 
>o—_—————————————>o 


NOTE: TPN on right gets no indication that DEALLOCATE_ABEND occurred 
because everything (including FMHs) are discarded when in purge state. 


LIC,CEB, 


Figure 2-77. DEALLOCATE ABEND Issued in SEND State --Remote LU 
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TP PS RMS | (to partner LU) | 
in RCV state | | 


DEALLOCATE_ABEND § —SOSEND_ERROR 
RCVO_DATA(DATA,NOT_END_OF_DATA) FIC,data 
o< eaiieats o< (1) 
purge 
- =RSP( 0846 ) hea 
, > (2). 
RCVD_DATA( PREPARE_TO_RCV_FLUSH) LIC, RQE1,CD»no data 


SS ho) 


- SEND_DATA(FMH DATA, - 


DEALLOCATE_FLUSH ) OIC,CEB,RQD1 ,FMH7( 0864) 


| DEALLOcATE_RCB FREE_SESSION +RSP 

- emreeenannee >o<— ———O< (5) 
RC=0K RCB_DEALLOCATED | 

——_—_—_—_—_—_——< _ 


Figure 2-78. DEALLOCATE ABEND Issued in RCV, Between-Chain State --Local LU 


ee SS 
ag 
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(3) 


(9) 


(5) 


artn H A | | T 


FIC,data SEND_DATA( DATA,NOT_END_OF_DATA) SEND_DATA 
<———$—$— $— — $ ox forte 


| RC=0K 
>o 


—RSP( 0846) RCVD_ERROR 
ns ae 
LIC,RQE1,CD,no data SEND_DATA( PREPARE_TO_RCV_FLUSH) SEND_DATA 


RCVD_DATA(FMH,DATA; 
OIC,CEB,RQD1 , FMH7( 0864) DEALLOCATE_FLUSH ) RC=DEALLOCATE_ABEND 
move D> eee errr erences tne AREAS RLREEREM TEES} (Yemen ensure ners cecernenenaremeeers (> §Y 


+RSP | DEALLOCATE_RCB DEALLOCATE_LOCAL | 
< . eRe 
| RCB_DEALLOCATED RC=0K 
' ' DP Oprrresen nmr nnirmtnmmemimminamianonens DED 
FREE_SESSION 
>o 


Figure 2-79. DEALLOCATE ABEND Issued in RCV, Between-Chain State --Remote LU 
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(to partner LU) 


RECEIVE_AND_WAIT 
eee 2 


RC=O0K » WHAT_RCVD= 


DATA_¥COMPLETE RCVD_DATA(DATA,NOT_END_OF_DATA). 


”. FIC, data i 


DEALLOCATE_ABEND SEND_ERROR RS PC 0846 ) 


RCVD_DATA(PREPARE_TO_RCV_FLUSH) ~-—- LIC,RQE1,CD,no data 


o< 


SEND_DATA(FMH,»DATA, = ete _ _ 
- DEALLOCATE_FLUSH) =. *——s« OIC, CEB, RQD1, FMH7(0864) 


. ; . > (4) 
DEALLOCATE_RCB  §=  FREE_SESSION | +RSP 
| , ers ei = 


o< 


RC=0K RCB_DEALLOCATED | Bs 


Figure 2-80. DEALLOCATE ABEND Issued in RCV, In-Chain State --Local LU 
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(to partner LU) | H _RM | PS TP 


FIC, data SEND_DATACDATA,NOT_END_OF_DATA) SEND_DATA 
(1) < o< O—— 0 
| | RC=0K 
>o 
—RSP( 0846 ) RCVD_ERROR 
(0o—_—_——_——_:::? «Oe OO 
LIC,RQE1,CD,no data SEND_DATA( PREPARE_TO_RCV_FLUSH ) SEND_DATA 
(3) < ) o< o< 


RCVD_DATA( FMH DATA, 
OIC, CEB, RQD1 »FMH7( 0864) DEALLOCATE_FLUSH) RC=DEALLOCATE_ABEND 
(4) ——————— 7 0 


+RSP | DEALLOCATE_RCB DEALLOCATE_LOCAL | 
(5) < 0< —— 
| RCB_DEALLOCATED RC=OK 
eG 


=o 


FREE_SESSION 


Figure 2-81. DEALLOCATE ABEND Issued in RCV; In-Chain State --Remote LU 
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TP PS RM | HS(FSP) = = (to partner LU) 
ALLOC( delayed) ALLOCATE_RCB 


RC=0K RCB_ALLOCATED(OK ) | 
rahe — 
| SEND_DATA 
>0 
RC=0K | 
o< 


[DEALLOCATE_FLUSH GET_SESS(ATTACH) BID_WITH_ATTACH OIC,BB,CEB,RQE1,ATTACH, data 


SS 


SESSION_ALLOCATED( OK } | 
o< 
| HS_PS_CONNECTED 


~>o 


FREE_SESSION | 
>o< 


DEALLOCATE_RCB 


RC=0K RCB_DEALLOCATED 
C—O K 


Figure 2-82. ALLOCATE (delayed), DEALLOCATE FLUSH (by First Speaker) --Local LU 
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ce) rtner ) 


OIC,BB,CEB,RQE1,ATTACH, data 
AQ—_——_—_—_—_—_—_—_—_—_—_—_—<—€—¥—¥—s«—«<—s—¥K—K<eaK—<—K—<—<X—X<X—s—SXS—sa—y-— 


Figure 2-83. 


HS(Bidder ) RM : PS TP 


BIO 


PQ 0 


BID_RSP( POS) | 
o< 
| ATTACH_HEADER ATTACH 
nN 


HS_PS_CONNECTED | RECEIVE_AND_WAIT | 
o< o< 
RCVD_DATA(DATA, RC=OK, 
DEALLOCATE_FLUSH) WHAT _RCVD=DATA_*COMPLETE 
DD 
| FREE_SESSION RECEIVE_AND_WAIT | 
>o o< 


|RC=DEALLOC_NORMAL 
>o 


DEALLOCATE_RCB DEALLOCATE_LOCAL 
© hs ao seoereeeeenaeeeeianemmemnnneimmmnen © 
| RCB_DEALLOCATED RC=0K 


DO 0 


ALLOCATE (delayed), DEALLOCATE FLUSH (by First Speaker) ~--Remote LU 
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TP PS RM HS( Bidder) (to partner LU) 


ALLOC( delayed) ALLOCATE_RCB 
a aN ate 


RC=0K RCB_ALLOCATED( OK ) | 
o< o< 
| SEND_DATA 
>o 
RC=OK | 
o< 


|DEALLOCATE_CONFIRM GET_SESS(ATTACH) BID_WITH_ATTACH OIC,BB,CEB,RQD2|3,ATTACH, data 
es 


SESSION_ALLOCATED(OK | 
o< 
| HS_PS_CONNECTED 


CONFIRMED : +RSP 
rrr) C neem (2) 


| DEALLOCATE_RCB FREE_SESSION | 
>o< 


RCB_DEALLOCATED 


Figure 2-84. ALLOCATE (delayed), DEALLOCATE CONFIRM (BY First Speaker) --Local LU 
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(to partner LU) HSCFSP ) RM PS TP 


(1) 


(2) < 


Figure 2-85. 


OIC,BB,CEB,RQD2|3,ATTACH,data BID 


BID_RSP( POS) | 
o< 
| ATTACH_HEADER ATTACH 
Te) 


HS_PS_CONNECTED | RECEIVE_AND_WAIT | 
o< o< 


RCVD_DATA(DATA, RC=O0K,» 
DEALLOCATE_CONFIRM) WHAT_RCVD=DATA_*®COMPLETE 
———— nee IO 


RECEIVE_AND_WAIT | 
o< 


RC=OK, 
WHAT_RCVD=CONF IRM 
>0 


+RSP CONFIRMED CONFIRMED | 
a RS 


FREE ©"SSION | RC=NONE 

- -cmmnarmneumsancnieenenmensicas > () >0 
RECEIVE _AND_WAIT | 

o< 

| RC=DEALLOC_NORMAL 

>0 
DEALLOCATE_RCB DEALLOCATE_LOCAL | 

——— ye 

| RCB_DEALLOCATED RC-O0K 

$66 eee OG 


ALLOCATE (delayed), DEALLOCATE CONFIRM (BY First Speaker) --Remote LU 
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TP | PS RM | HS(Bidder) (to partner LU) 
ALLOC( delayed)  ALLOCATE_RCB | | 


RC=0K RCB_ALLOCATED( OK) | 
| 0 Geen ee @ he 
| SEND_DATA 
>o 
RC=0K | 
fo ] 


< 
[DEALLOCATE_FLUSH GET_SESS(ATTACH)  BID_WITH_ATTACH OIC,BB,CEB,RQD1,ATTACH, data 


Dern entnercrrentninennretnanen > fYpestenmmitetnsatniattaintainancnrsininmmnees > (prenscntonaneiamuannnenmnemenicinnieninarsarenrenimenereeecmremcncemencas > J } 


~ SESSION_ALLOCATED(OK) BID_RSP(POS) +RSP 
nnn CC rere ( 2) 


| HS_PS_CONNECTED 
>0 


DEALLOCATE_RCB FREE_SESSION 
-20O< 
RC=-0K RCB_DEALLOCATED | 
O—_——_—_—_———— OC 


Figure 2-86. ALLOCATE (delayed), DEALLOCATE FLUSH (by Bidder) to RECEIVE_AND_WAIT --Local LU 
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(to partner LU) HS( FSP) RM PS TP 


OIC,BB,CEB,RQD1,ATTACH, data BID 
1) —_—_————_—___—_—------—"n— 0 


BID_RSP( POS) | 
o< 
| ATTACH_HEADER ATTACH 
Dr rere Perera steers 1 () 


HS_PS_CONNECTED | RECEIVE_AND_WAIT | 
o< o< 


RCVD_DATA(DATA; RC=0OK; 

DEALLOCATE_FLUSH ) WHAT_RCVD=DATA_*COMPLETE 
Dp rtm EF 
| +RSP | RECEIVE _AND_WAIT | 

(2) < : o< 

| FREE_SESSION [RC=DEALLOC_NORMAL 

>o 70 
DEALLOCATE_RCB DEALLOCATE_LOCAL | 

Gt ee a he 

| RCB_DEALLOCATED RC=OK 

DC eaemesensenanemacramemanainaemmeneminanes 


Figure 2-87. ALLOCATE (delayed), DEALLOCATE FLUSH (by Bidder) to RECEIVE_AND_WAIT --Remote LU 
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TR PS RCS Bidder) (to partner LU) 
ALLOC( delayed) ALLOCATE_RCB 


RC=0K RCB_ALLOCATED( OK } | 
(© Sommammiamemmenmeiemnmeiammmeememeedt © ho 
| SEND_DATA 
>0 
RC=OK | 
o<« 


| DEALLOC_FLUSH GET_SESS(ATTACH) BID_WITH_ATTACH OIC,BB,CEB,RQD1,ATTACH, data 


SESSION_ALLOCATED(OK) BID_RSP(POS) +RSP 
© 9 2) 
| HS_PS_CONNECTED 
>o 


DEALLOCATE_RCB FREE_SESSION | 
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Figure 2-88. ALLOCATE (delayed), DEALLOCATE FLUSH (by Bidder) to SEND_ERROR --Local LU 
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(to partner LU) HSCFSP) RM PS TP 


OIC,BB,CEB,RQD1,ATTACH, data BID 
D0 e———— — — eee 
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Figure 2-89. ALLOCATE (delayed), DEALLOCATE FLUSH (by Bidder) to SEND_ERROR --Remote LU 
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RC=0K RCB_DEALLOCATED 


Figure 2-90. ALLOCATE (delayed), DEALLOCATE CONFIRM (by Bidder) --Local LU 
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(to partner LU) | 


(to partner LU) FS s T 


OIC,BB,CEB,RQD2|3,ATTACH,data BID 
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o< o< 


RCVD_DATA(DATA, RC=-OK, 
DEALLOCATE_CONFIRM) WHAT_RCVD=DATA_*COMPLETE 
= —_—_—_—_—_—S—SSNHO 
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Figure 2-91. ALLOCATE (delayed), DEALLOCATE CONFIRM (by Bidder) --Remote LU 
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TP PS | RMS ——~*séC partner LUD 


SEND_DATA 
RC=0K | . 
o< 


CONFIRM _ SEND —DATA(DATA, CONFIRM) — | 7 ore Ra02|3,DATA 
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Figure 2-92. CONFIRM (RQD213) --Local LU 
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(to partner LU) : HS _ M | , PS TP 


RECEIVE_AND_WAIT 


C6 
RC=OK, 
OIC, RQD2|3,DATA . RCVD_DATA(DATA,CONFIRM) . WHAT_RCVD=DATA_*COMPLETE 


(1) 
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Figure 2-93. CONFIRM (RQD2/3) --Remote LU 
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(to partner LU) 


SEND_DATA 


RC=0K | 
o< 
| PREPARE —TO_ RECEIVE 


>0 
NO RC 
o< _ SEND_DATAC(DATA, 
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| RECEIVE_AND_WAIT | 
>0 i | ; 


RC=OK »WHAT_RCVD= 


DATA_*COMPLETE RCVD_DATA( DATA, NOT_END_OF_DATA) 
ae OK , , . . 


Figure 2-94. CONFIRM (RQE2/3) --Local LU 
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OIC ,RQE2]3,CD,DATA 
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FIC, data 
(2) < 


$ S TP 


RECEIVE_AND_WAIT 
creme C) 
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Figure 2-95. CONFIRM (RQE213) --Remote LU 
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(to partner LU) 
SEND_DATA 
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RC=0K 
o< 
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NO RC | | , 
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from FMH7" RCVD_DATACFMH,DATA,NOT_END_OF_DATA) Ps : FIC, FMH7,DATA 


Figure 2-96. CONFIRM (RQE213), SENO_LERROR --Local LU 
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RECEIVE_AND_WAIT 


(«6 eee °) 
RCVD_DATA(DATA, RC=OK; 
OIC, RQE2|3,CD,DATA  PREPARE_TO_RCV_CONFIRM) |= WHAT_RCVD=DATA_*COMPLETE 
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| RC=OK ,WHAT_RCVD= 
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Figure 2-97. CONFIRM (RQE213), SEND_ERROR --Remote LU 
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TP_ 


se PS eee |, eee __HS 


SEND_DATA 
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| SEND_DATA 
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Figure 2-98. CONFIRM (RQD2/13), SEND_ERROR --Local LU 
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RECEIVE _ANO_WAIT 
«eee °) 
RC=OK, 
OIC,RQD2|3,-CD,DATA RCVD_DATA( DATA, CONFIRM) WHAT_RCVD=DATA_*COMPLETE 
Se ee OG 


RECEIVE _AND_WAIT | 
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Figure 2-99. CONFIRM (RQD213), SEND_ERROR --Remote LU 
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TP PS a _RM__ HS 
SEND_DATA 


(to partner LU) 


nn OO” 


RC-OK | 
o< 
| SEND_DATA = ~—~—s SEND_DATA(DATA,NOT_END_OF_DATA) FIC, data 
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» d * aaee nena 6 een A (2) 


Figure 2-100. RECEIVE_AND_WAIT Causing RQE,CP --Local LU 
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(to partner LU) HS RM PS TP 


RECEIVE_AND_WAIT 


O——— 0 
. RC=0K; 
FIC,data RCVD_DATA(DATA,NOT_END_OF_DATA) WHAT_RCVD=DATA_INCOMPLETE 


CR) sa es 
RCVD_DATA(DATA, 
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Figure 2-101. RECEIVE_AND_WAIT Causing RQE,CD --Remote LU 
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TP , PS | RM HS (to partner LU) 
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Figure 2-102. SEND_ERROR before SEND_DATA --Remote LU 
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(to partner LU) HS RM PS TP 


RECEIVE_AND_WAIT 


o6—_____________—- 
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Figure 2-103. SEND_ERROR before SEND_DATA --Local LU 
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Figure 2-104. SEND_ERROR Crossing SEND_ERROR, Both Issued in Receive State --Remote LU 
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(to partner LU) HS RM PS TP 
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Figure 2-105. SEND_ERROR Crossing SEND_ERROR, Both Issued in Receive State --Local LU 
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TP PS | __ RM ~_ HS | (to partner LU) 
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Figure 2-106. SEND_ERROR before CONFIRM --Remote LU 
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TP PS RM __HS (to partner LU) 


SEND_DATA 
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Figure 2-108. SEND_ERROR at End-of-Chain --Remote LU 
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(to partner LU) RM PS TP 


RECEIVE_AND_WAIT 
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Figure 2-109. SEND_ERROR at End-of-Chain --Local LU 
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IP _PS ___RM : HS | (to partner LU) 
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ag ae 


RC=0K | 
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RECEIVE_AND_WAIT PREPARE_TO_RCV_FLUSH) LIC,RQE1,CD 


Figure 2-110. REQUEST_TO_SEND, Received in Send State --Remote LU 
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(to partner LU) HS RM | PS TP 
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>o 
SIGNAL REQUEST_TO_SEND REQUEST_TO_SEND | 
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CY ccleaner ter ee eG 
RECEIVE_AND_WAIT 


o< 


RC=0K ,»WHAT_RCVD= 
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Figure 2-111. REQUEST_TO_SEND, Received in Send State --Local LU 
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Figure 2-112. REQUEST_TO_SEND, Received in Receive State --Remote LU | 
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(to partner LU) S RM PS TP 
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—_—_—_——_— OO 
FIC, data RCVD_DATA(DATA,NOT_END_OF_DATA) 
| ——— 7? ny ROOK ,WHAT_RCVD= 


| DATA_*COMPLETE 
>o 
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0 ny Yd 


LIC,»RQE1,| CD RCVD_DATA( DATA, PREPARE_TO_RCV_FLUSH) 
BY a a eG 
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(Q)0 ———— 9 7? ee ep 
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RC=CK, WHAT_RCVD= 
DATA_*COMPLETE 
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Figure 2-113. REQUEST_TO_SEND, Received in Receive State --Local LU 
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CHAPTER 3. LU RESOURCES MANAGER 


Transaction 
Program 


Presentation 
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(PS) 


Resources 
Manager 
(LU.SVC_MGR.RM) 


Data Flow 
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Control 
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LU Network 
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(LU.SVC_MGR.NS) 


Figure 3-1. Overview of Component Interactions Involving the Resources Manager 


GENERAL DESCRIPTION 


Any time one transaction program wishes to 
communicate with another, the LU needs to 
establish, manage, and later deactivate a 
conversation. This chapter describes the 
management of conversation resources (or sim- 
ply conversations"). 


An LU contains a services manager, which in 
| turn contains a resources manager, RM. The 
resources manager stores information about 
active transaction programs, conversations, 
and LU-LU sessions in control blocks, some of 


which are the TCB, RCB, and the SCB (see "Re- 
sources Manager Data-Base" on page 3-3 for 
additional information). 


The resources manager interacts with other 
components within the LU. These components 
are shown in Figure 3-1. They are PS ("Chap- 
ter 5.0. Overview of Presentation Services" 
and "Chapter 5.1. Presentation Serv- 
ices--Conversation Verbs"), LNS ("Chapter 4. 
LU Network Services"), and HS ("Chapter 6.0. 
Half-Session''). 
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RESOURCES MANAGER FUNCTIONS 


The resources manager (RM) coordinates the 
following functions: 


e 6Creating new instances, and destroying 
existing instances, of presentation serv- 
ices 


e Attaching new instances, and destroying 
existing instances, of transaction pro- 
grams 


® Establishing conversations and deactivat- 
ing conversations 


® Choosing sessions to be used by a conver- 
sation and, if necessary, requesting 
(bidding for) use of the session 


® Requesting network services (LNS) to 
activate a new session or to deactivate 
an existing session 


LU COMPONENT INTERACTIONS 


3-2 


Other components, in the LU, with which the 
resources manager interacts are the presenta- 
tion services (PS) component associated with 
each transaction program instance attached to 
the LU, each half-session (HS) that is avail- 
able for use by the resources manager, and 
network services (LNS). Examples of the type 
of interactions that take place are given 
below. 


When presentation services is requested by 
its transaction program (TP) to initiate a 
conversation with another TP, it requests the 
resources manager to assist in the request. 
The resources manager is responsible for such 
tasks as choosing a session on which to ini- 
tiate the conversation; checking that the 
synchronization level, and security level on 
the request corresponds to that which the 
target LU supports for this LU; and perfora- 
ing other functions necessary for acquiring 
the session for use by the requested conver- 
sation, such as creating the appropriate con- 
trol blocks (see “Resources Manager 
Data-Base"' on page 3-3 for more on control 
blocks). After the resources manager has 
completed processing of the request that it 
received from presentation services, it sends 
a reply to PS informing it of the outcome of 
the request. 


One type of unsolicited information that the 
resources manager sends to presentation serv- 
ices 1s an Attach FM header (FMH-5). When 
the resources manager receives an Attach from 
a remote LU over one of its half-sessions, it 
checks certain fields, including all security 


{ fields, 


e Completing LU-LU verification (FMH-12 


processing) 


® Replying to requests (bids) for use of a 
session that are received from remote 
resources managers 


®¢ Providing services for support of the 
syne point log (the content and use of 
which is described in "Chapter 5.3. Pres- 
entation Services--Syne Point Services 
Verbs" )——these services are not formally 
defined in this book 


* Coordinating and 


managing 
conversation-level security 


carried in the Attach; then it cre- 
ates a new instance of presentation services . 
and sends the Attach, along with other infor- 
mation, to the new PS ("Attaching a Trans- 
action Program" on page 3-9 and "Creation 
and Termination of Presentation Services" on 
page 3-17 provide additional details). 


Data that the resources manager wishes to 
send to another resources manager in the net- 
work is first sent to the local HS component 
of one of the sessions comecting the two 
LUs . Likewise, the resources manager 
receives from HS all data destined for the 
resources manager that comes in over a ses- 
sion. Examples of the kind of data that 
flows between the resources manager and HS 
are bids for the use of a session, replies to 
bid requests, and Attach FM headers. 


When the resources manager receives a request 
from presentation services for a session and 
it finds that there are no free sessions with 
the required characteristics, the resources 
manager sends a request to LNS asking it to 
activate a new session. Similarly, the 
resources manager sends to LU network serv- 
ices a request that a session be deactivated 
upon notification by PC.COPR ("Chapter 5.4. 
Presentation Services--Control-Operator 
Verbs") that too many sessions are active. 
LNS replies to the resources manager after 1t 
has carried out the requested function. See 
“Activating a New Session" on page 3-13 and 
"Changing the Maximum Session Limit" on page 
3-15 for more details on session activation 
and deactivation. 
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RESOURCES MANAGER DATA-BASE 


The resources manager needs information about 
such things as the transaction programs cur- 
rently attached to the LU, the conversations 
associated with each transaction program, and 
the sessions available for use by a conversa- 
tion between transaction programs. This 
information is stored in a group of control 
blocks found in the LU (see "Appendix A. Node 
Data Structures" for the control block defi- 
nitions). The resources manager initializes 
entries in some control blocks, while it only 
accesses or updates information in entries 
already existing in other control blocks. 


CONTROL BLOCKS MAINTAINED BY THE RESOURCES 
MANAGER 


Information about transaction programs § is 
contained in the transaction control block 
(TCB). One TCB exists for each active TP-PS 
process associated with the LU. Each TCB 
contains a TCB identifier (TCB_ID), which 
uniquely identifies the transaction program 
being represented by the TCB. The TCB_ID is 
also used in all communication between the 
resources manager and presentation services 
servicing the transaction program. For exan- 
ple, when presentation services sends a 
record to the resources manager, it provides 
its TCB_ID so that the resources manager will 
know, of all the TP-PS processes it manages, 
which presentation services to send a reply 
to. Presentation services is informed of its 
TCB_ID when the TP-PS process is created by 
the resources manager. When the resources 
manager receives an Attach header (FMH-5) 
from a remote resources manager, it creates a 
new TCB, creates a new instance of presenta- 
tion services to be associated with the 
transaction program being attached, and sends 
the TCB_ID of the new TCB to presentation 


services. Thus, attaching a transaction pro- 
gram results in creation of a new TP-PS proc- 
ess for that transaction program, with which 
a presentation services component is always 
associated. 


Associated with each TCB is a grou of 
resource control blocks (RCBs). One RCB 
exists in the group for each conversation 
associated with the transaction program. 
Besides the RCB_ID, an RCB contains several 
other pieces of information, such as the 
TCB_ID of the TP-PS process that is using the 
conversation; the LU name, mode name, and 
half-session identifier (HS_ID) of the ses~ 
sion on which a conversation is running; and 
a buffer in which presentation § services 
stores data that it receives from the trans- 
action program. 


The final control block maintained by the 
resources manager 1s the session control 
block (SCB). One SCB exists for each active 
session between the LU and a partner LU. 
Information contained in an SCB includes a 
half-session identifier (HS_ID) and the part- 
ner LU_NAME and MODE_NAME for the session. 
CONTROL BLOCKS ACCESSED BY THE RESOURCES MAN- 
AGER 


In addition to those control blocks managed 
by the resources manager, other control 
blocks exist that are managed by another com- 
ponent but are accessed and updated by the 
resources manager. 


One of these control blocks ts MODE. There 
is one MODE control block for each mode name 
that is defined for the particular LU. The 
MODE entry contains information that is fixed 
on a mode name basis such as session counts 
and session limits. 


Resources 


Manager 


Transaction Presentation 
rogram Services 
ALLOCATE 
> 
ALLOCATE_RCB 
RCB_ALLOCATED(RCB_ID) 

€ 

Figure 3-2. Allocation of a Resource Control Block (RCB) 


Chapter 3. LU Resources Manager 3-3 


ESTABLISHING A CONVERSATION 
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When the resources manager receives an 
ATTACH_HEADER record (from HS if the Attach 
was received on an LU-LU session, or from 
UPM_IPL if the Attach was generated locally, 
perhaps as the result of an operator com- 
mand), it creates a new TCB (representing the 
new instance of a TP-PS process) and RCB (re- 
presenting the transaction program's initial 
conversation). It passes the IDs of the con- 
trol blocks to the newly-created presentation 
services process (see "Attaching a Trans- 
action Program’ on page 3-9). Once the 
transaction program is attached, it can ini- 
tiate conversations with other transaction 
programs. 


ALLOCATING A NEW CONVERSATION 


When the transaction program is ready to 
start a new conversation, it issues an ALLO- 
CATE verb to presentation services. In gen- 
eral, presentation services separates the 
ALLOCATE request into two distinct functions, 
1.@., allocating an RCB and obtaining a ses- 
sion. Presentation services requests the 
resources manager to create a new RCB via an 
ALLOCATE_RCB record. The ALLOCATE_RCB con- 
tains information about the type of session 
that will be needed for the conversation. It 
stores the session-related information in the 
new RCB and sends presentation services an 
RCB_ALLOCATED record, which contains the ID 
of the RCB. See Figure 3-2 for the flows 
that take place. 


OBTAINING A SESSION 


Once presentation services (PS) is informed 
of the ID of the new RCB, it creates an 
Attach FM header (FMH-5) and places it in the 
RCB. At some point, it requests that an 
LU-LU session be allocated to the conversa- 
tion. PS can choose to return control to the 
transaction program and later obtain the nec- 
essary session, or it can obtain the session 
before returning to the transaction program. 
PS makes the decision of when to ask for the 


session based on information the transaction 
program supplied in the ALLOCATE verb (see 


"Chapter 5.1. Presentation Serv- 
ices--Conversation Verbs" for specific 
details). | 


Presentation services asks for a session to 
be allocated by sending a GET_SESSION record 
to the resources manager. The GET_SESSION 
contains the RCB_ID of the conversation that 
is to use the session. It also contains an 
indicator that tells the resources manager 
whether PS wants RM to send out the Attach FM 
header as part of the session allocation 
processing, or whether PS is to be responsi- 
ble for sending the Attach after the session 
has been allocated by RM. 


The resources manager at either end of a ses- 
Sion connecting two LUs may attempt to allo- 
cate that session to a conversation. If both 
resources managers attempt to allocate the 
same session at the same time, there must be 
some way to resolve the contention for the 
session. For this reason, one of the LUs is 
designated the "first speaker" (Cor "con- 
tention winner'') and the other LU is desig- 
nated the "bidder" (or "contention loser") 
for the session. The assignment of 
first-speaker and bidder LUs is established 
during session activation and remains in 
effect for the duration of the session. If 
more than one session exists between a pair 
of LUs, one LU may be the first speaker for 
some sessions and the bidder for the others. 
If an LU is the first speaker for a partic- 
ular session, that session is said to be a 
first-speaker session for the LU. | 


The resources manager in a bidder LU must 
request the resources manager in the 
first-speaker LU for permission to use a ses- 
sion. This is called "bidding" for a ses- 
sion. The first-speaker LU may either grant 
or deny the request for the session from the 
bidder LU. On the other hand, if the 
resources manager in ae first-speaker = LU 
wishes to allocate a free session to a con- 
versation, it may do so immediately, without 
requesting permission from the resources man- 
ager in the other LU. 
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(4) 


(5) 


(2) 


(3) 


(4) 


(5) 


Figure 3-3. 


The resources manager will always allocate a 
first-speaker session in preference to a bid- 
der session, to avoid the bidding procedure. 
Figure 3-3 illustrates the flows that take 
place when the resources manager attempts to 
allocate a session and presentation services 
has specified that the Attach is not to be 
sent by RM as part of the session allocation. 
The records used in the figure are defined in 
“Appendix A. Node Data Structures" in more 
detail. The following description refers to 
the numbers to the left of each flow in the 
figure. 


(1) Presentation services sends a 
GET_SESSION record to the resources man- 
ager. The RCB_ID identifies an RCB that 
was previously allocated by the 
resources manager. The NO_ATTACH param- 
eter informs the resources manager that 
it should not send the Attach FM header 
as part of the session allocation proc- 
essing 


(2) If no first-speaker session is avail- 
able, the resources manager must bid for 
use of a session. It sends 
BID_WITHOUT_ATTACH to the half-session. 
The bid will flow on the session *o the 
resources manager at the partner LU. 
Between the time that the bid is sent 


Allocation of Session Using BID_WITHOUT_ATTACH 


(3) 


(4) 


(5) 


Presentation Resources 
Services Manager HS 
GET_SESSION(RCB_ID, NO_ATTACH) 
> 
HS_PS_CONNECTED 
First- > 
Speaker 
Flows SESSION_ALLOCATED 
< 
-OR- 
BID_WITHOUT_ATTACH 
> 
@ 
@ 
@ 
Bidder 
Flows +BID_RSP 
< 
HS_PS_CONNECTED. 
> 
SESSION_ALLOCATED 
< 


and the bid response is received, the 
resources manager must retain enough 
information to be able to proceed with 
session allocation when the bid response 
arrives. This information includes sav- 
ing the HS_ID of the session and the 
GET_SESSION record in the RCB. 


The BID_RSP arrives from the remote 
resources manager on the half-session. 
The positive response indicates that the 
bid for use of the session has been 
accepted and the resources manager can 
complete the session allocation. Not 
shown in this figure is the processing 
of a ~-BID_RSP. In this case, the 
resources manager would attempt allo- 
cation of a different session, if possi- 
ble. 


An HS_PS_CONNECTED record is sent to the 
half-session to inform the half_session 
that it has been connected to a TP-PS 
process. 


A SESSION_ALLOCATED record is sent to 
presentation services to inform it that 
® Sastion has been allocated to the con- 
versation, satisfying the GET_SESSION 
request. 
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(1) 


(2a) 


(4) 


(5) 


(2b) 


(3) 


(4) 


(5) 


Figure 3-4. 


Presentation Resources 
Services Manager 
GET_SESSION(RCB_ID, ATTACH) 
> 
First- 
Speaker 
Flows 
SESSION_ALLOCATED 
2 | 
-OR- 
Bidder 
Flows 
< 
SESSION_ALLOCATED 
< 


HS 
BID_WITH_ATTACH 
> 
HS_PS_CONNECTED 
> 
BID_WITH_ATTACH 
> 
@ 
@ 
@ 
+BID_RSP 
HS_PS_CONNECTED 
> 


Allocation of Session Using BID_WITH_ATTACH 
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Figure 3-4 illustrates the flows that take 
place when the resources manager attempts to 
allocate a session and presentation services 
has specified that the Attach is to be sent 
by RM as part the the session allocation. 


The records used in the figure are fully 
defined in "Appendix A. Node Data Struc- 
tures". The following description refers to 


the numbers to the left of each flow in the 
figure. 

(1) Presentation services sends a 
GET_SESSION record to the resources man- 
ager. The RCB_ID identifies an RCB that 
was previously allocated by the 
resources manager. The ATTACH parameter 
informs the resources manager that it 
should send the Attach FM header as part 
of the session allocation processing 
(2a) If a first-speaker session is available, 
a BID_WITH_ATTACH to the half-session. 
The BID_WITH_ATTACH contains the Attach 


(2b) 


(3) 
(4) 


(5) 
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FM header as a field. Since this is a 
first-speaker session, the 
BID_WITH_ATTACH is not really a bid for 
the session, and RM may immediately pro- 
ceed with session allocation without 
waiting for a BID_RSP (none will be 
forthcoming). 


If no first-speaker session is avail- 
able, the resources manager must bid for 
use of a session. It sends 
BID_WITH_ATTACH to the half-session. 
BID_WITH_ATTACH includes the Attach FM 
header as a field. The Attach is sent 
on the half-session along with the bid. 
Otherwise, the processing is the same as 
in Figure 3-3. 


Same as in Figure 3-3 


Same as in Figure 3-3 


Same as in Figure 3-3 


Resources Presentation 
HS Manager Services 
BID 

(1) > 

BID_RSP 
(2a) < 

ATTACH_HEADER 
(3) > 
ATTACH_RECEIVED 
(4) > 
-~OR- 

-BID_RSP 
(2b) < 
Figure 3-5. Responding to a Bid for a Session 

Figure 3-5 illustrates the flows that take essing continues with receipt of the 


place when a bid request is received by the 
resources manager. The records used in the 
figure are defined in "Appendix A. Node Data 
Structures" in more detail. The following 
description refers to the numbers to the left 
of each flow in the figure. 


A BID record is received from the 
half-session. The half-session sends a 
BID record to RM whenever the partner LU 
sends BB, regardless of whether the 
partner LU is bidder or first speaker. 


(1) 


(2a) If RM responds with a +BID_RSP, the 
request by the remote resources manager 


to use the session is accepted and proc- 


(2b) 


(3) 


(4) 


Attach FM header from the half-session 
(flows 3 and 4). 


If RM responds with a -BID_RSP, the 
request by the remote resources manager 
to use the session is rejected. 


An ATTACH HEADER record, which includes 
the FMH-5, 1s sent from the half-session 
to RM. 


TP-PS and sends 
See "Attaching a 
on page 3-9 for 


RM creates ao new 
ATTACH_RECEIVED to PS. 
Transaction Program" 
further details. 
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‘Presentation | ) Resources 


Services : Manager HS 
ALLOCATE_RCB( IMMEDIATE_SESSION = YES) 
a ee 
HS_PS_CONNECTED 
First-Speaker | . > 
Sessior 
Available RCB_ALLOCATED(RCB_ID) 
a nl 
-OR- 
First-Speaker RCB_ALLOCATED 
Session (RETURN_CODE = UNSUCCESSFUL) 


Not Available [| < 


Figure 3-6. Immediate Allocation of a Session 


ssneenneenreeepemenenenneeemennee . . 


IMMEDIATE SESSION PROCESSING 


Presentation services. can request the 
resources manager to allocate both an RCB and 
a session with one record. ALLO- 
CATE_RCB( IMMEDIATE_SESSION=YES) embodies the 
function of both ALLOCATE_RCB and GET_SESSION | 
in that when the processing completes suc-. 


cessfully, both an RCB and an SCB are allo- 


. cated. ALLOCATE_RCBC IMMEDIATE_SESSION=YES ) 


instructs the resources manager to allocate 


an RCB only if a first-speaker half-session 
4s. currently available. If such a 


half-session is not available, no allocation 
is to be performed. See Figure 3-6 for the 


specific flows involved. _ 
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Resources 


HS Manager 
ATTACH_HEADER 
> 
HS_PS_ CONNECTED 
< 


Figure 3-7. 


Presentation 
Services 


ATTACH_RECEIVED (TCB_ID, RCB_ID, 
SENSE_CODE ) 


Attach Flons 


TTACHING A TRANSACTIC. eRxUGRAM 


One transaction program requests via an 
Attach FM header (FMH-5) that another trans- 
action program be attachea to a conversation. 
The resources manager handles the receipt of 
the Attach. Only one Attach is sent per con- 
versation. RM processes the Attach and later 
sends it to PS_INITIALIZE in the newly cre- 
ated TP-PS process for further processing. 


RM is responsible for checking certain fields 
of the Attach, such as the transaction pro- 
gram name field. RM performs all security 
checks of the Attach. (PS_INITIALIZE later 
checks the remaining fields). It notifies 
presentation services of the result of the 
checking through a field in the ATTACH record 
that RM sends to PS. 


If the Attach violates established protocol 
(e.g.» by sending an Already Verified: indi- 
cation to a partner LU that does not accept 
it, sending multiple passwords on a single 
Attach, indicating a synchronization level of 
syncpoint when the level for the session is 


> 


confirm-only), RM causes an UNBIND to be gen- 
erated and does not create a new instance of 
the TP-PS process. For all other errors 
found in the Attach (e.g., invalid user ID, 
invalid parameter length), PS is responsible 
for creating an FMH-7 or for causing an 
UNBIND to be generated, to notify the trans- 
action program that initiated the Attach of 
the error. 


If after checking the Attach no protocol 
error is found, the resources manager creates 
a new instance of the TP-PS process; it cre- 
ates a new TCB and RCB; and it connects the 
TP-PS process to the half-session. It then 
sends an ATTACH record to the new instance of 
the TP-PS process. The ATTACH record con- 
tains the Attach FM header, the FMH-7 sense 
data field, and the IDs of the new TCB and 
RCB. Finally, it notifies the half-session 
that it has been connected to a TP-PS process 
via a HS_PS_CONNECTED record. Figure 3-7 
depicts the flows involved in Attach process- 
ing. 
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First-Speaker 


Resources 
Manager | HS ©ee HS 


BID_WITH_ATTACH 


\ 
Create RCB \ / 
RCB.HS_ID = HS_ID \N / 
SCB.RCB_ID = RCB_ID \N ¢4 
STATEC FSM_RCB_STATUS) = IN_USE x 
STATE(FSM_SCB_STATUS) = IN_USE 7 N 
/ \ 
/ \ 
BID / 


STATECFSM_SCB_STATUS) = IN_USE, so: 


Figure 3-8. 


Bidder 


_ Resources 
Manager 


BID_WITH_ATTACH or 
BID_WITHOUT_ATTACH 


Create RCB1 


RCB1.HS_ID = HS_ID 
SCB.RCB_ID = NULL 
STATEC FSM_RCB1_STATUS) = PENDING_ATTACH 
STATE( FSM_SCB_STATUS) = FREE 
BID 

> 
Create RCB2 
RCB2.HS_ID = HS_ID 
SCB.RCB_ID = RCB_ID 
STATE( FSM_RCB2_STATUS) = IN_USE 
STATE(FSM_SCB_STATUS) = IN_USE 


ATTACH is sent to PS 


-BID_RSP( SENSE_CODE = 0813 or 08149) 


Bid Races 


> 


RCB1.HS_ID = NULL 
STATE(FSM_RCB1. STATUS) = FREE 
Retry on another session 
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- $ession. 


ee  ) 8 hee 606 | lee 


It is possible for the resources manager on 
each end of a session to simultaneously 
choose that session to service separate 
GET_SESSION records, causing a bid race. The 
resources manager on the first-speaker side 
of the session always wins such a bid race. 
When it receives the bid from the bidder RM, 
it recognizes that the session is already in 
use and generates a negative BID_RSP. When 
the bidder RM receives the negative BID_RSP 
record, it checks the free session pool to 
see if there is another session available and 
retries the GET_SESSION processing on that 
Figure 3-8 illustrates an example 
of a bid race and shows the RCB and SCB set- 
tings that allow a race condition to be 
detected. | 7 


The negative BID_RSP that is generated for a 
bid rejection can have a sense code of either 
0813 (Bracket Bid Reject—No RTR Forthcoming) 
or 0814 (Bracket Bid Reject—RTR Forthcom- 
ing}. Either -BID_RSP( 0813) or 
~BID_RSP(0814) may be sent, the decision 
being an implementation-dependent choice. 

An implementation may permit a transaction 
program to reserve a session before a conver- 
sation is started on that session. A bid for 
a reserved session is always rejected with a 
-BID_RSP(0814) since the transaction program 
might never begin a conversation on the 
reserved session (if, for example, the trans- 
action program terminated abnormally). The 
resources manager informs the partner LU that 


it can bid on the session again by sending an 


RTR_RQ. 
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-BID_RSP(SENSE_CODE = 0814) 


> 
@ 
@ 
@ 
RTR_RQ 
> 
#RTR_RSP 
BID 
-OR~ 


-RTR_RSPCSENSE_CODE = 0819) 


Figure 3-9. READY TO RECEIVE (RTR) Flows 


Figure 3-9 depicts possible RTR flows. In 
the situation where there is a bid race and 
-BID_RSP( 0814) is sent, the resources manager 
at the bidder side of the session cannot bid 
again for that session until it has received 
~ an RTR_RQ from the first-speaker RM. Upon 
receipt of a -BID_RSP(0814), the bidder 
resources manager updates a field in the SCB 
to remember that -RSP(0814) was received and 
retries the bid on another session. From 
this point until the RTR_RQ is received, 
whenever a conversation ends and the session 
becomes free, the session is not returned to 
the free session pool (as is the normal 
case), thereby preventing the session from 
being chosen for bidding. : 


When the current conversation ends, the 
first-speaker RM returns the session to the 
free session pool and checks to see if any 
waiting requests can be satisfied by that 
session. The resources manager may use the 
session to service multiple GET SESSION 
requests before sending the promised RTR_RQ. 


At some point, the resources manager at the 
first-speaker side sends an RTR_RQ to the 


resources manager at the bidder side. This 
is a notification to the bidder RM that it 
can now use the session. When the 
first-speaker RM sends the RTR_RQ, it removes 
the session from the free session pool to 
prevent that session from being chosen to 
service a request before the bidder RM has 
had a chance to respond to the RTR_RQ. 


When the bidder RM receives the RTR_RQ, it 
places the session in the free session pool 
(for the first time since receiving the 
-BID_RSP(0814)). It then checks to see if a 
GET_SESSION record is waiting to be serviced, 
if so RM then sends a positive RTR_RSP Cindi- 
cating that it intends to use the session) 
and a BID_WITHOUT_ATTACH or BID_WITH_ATTACH 
to the first-speaker resources manager. If 
no GET_SESSION records are waiting, the bid- 
der sends a negative RTR_RSP with a sense 
code of 0819. This indicates to the 
first-speaker RM that the bidder does not 
need the session. At this time, the 
first-speaker places the session back into 
the free session pool and checks for any 
waiting requests. 
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FREE_SESSION 


FREE_SESSION 


Presentation Resources 
Services Manager 
DEALLOCATE_RCB(RCB_ID) 
> 
RCB_DEALLOCATED 
< 
e 
e 
6 
< 
-~OR- 
< 
© 
@ 
e 
DEALLOCATE_RCB(RCB_ID) 
-> 
RCB_DEALLOCATED 
< 
Note: 


Figure 3-10. 


DEALLOCATE_RCB and FREE_SESSION are independent records and can be sent to the resources 
manager in any erder. 


End of a Conversation 


TERMINATING A CONVERSATION 
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After the resources manager has established a 
conversation between two transaction pro- 
grams, it is not called upon to do any other 
processing for that conversation until the 
transaction programs are ready to end the 
conversation (see Figure 3-10). The 
resources manager is informed of the end of 
the conversation via two independent records. 
One record is DEALLOCATE_RCB, sent from pres- 


entation services. The other is 

FREE_SESSION, sent from HS to inform the 
resources manager that the session is now 
available for use by another conversation. 
The arrival of the two records '§ is. 
order-independent. Whichever record is 
received first triggers the resources manager 
to disconnect PS and HS. | . 
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SESSION_ALLOCATED 
0 ny 
~OR- 
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Figure 3-ll. Activation of a New Session 
ACTIVATING A NEW SESSION 
The resources manager allocates sessions to ices requests the session be allocated with a 
be used by conversations. Presentation serv-  GET_SESSION record. RM chooras sessions from 
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ie 


the free session pool to satisfy the 
GET_SESSION request. If the pool is empty 
and the session limits allow the activation 
of a new session, the resources manager sends 
an ACTIVATE_SESSION record, containing the LU 
name and mode name of the desired session, to 
LU network services (LNS, "Chapter 4. LU Net- 
work Services"). Figure 3-11 on page 3-13 
illustrates the flows involved in activating 
a new session. 


Although RM will not request session acti- 
vation if it would cause the session limits 
to be exceeded, LNS is ultimately responsible 
for checking to see that the number of active 
sessions is not greater than the maximum num- 
ber of sessions allowed for that (LU name, 
mode name) pair. Some conditions (e.g., a 
BIND race) will cause RM to request a session 
activation that would exceed the session lim- 
its. In this case, the activation request 
from RM is rejected with a negative ACTI- 
VATE_SESSION_RSP record. 


If the session can be activated, normal BIND 
protocols take place. When the session has 
been successfully activated, the LNS compo- 
nent sends the resources manager a positive 
ACTIVATE_SESSION_RSP record informing RM of 
the SCB_ID of the new session. 


Figure 3-11 shows the RM flows involved in 
activating a new session. In the following 
discussion, the numbers in parentheses corre- 
spond to the numbers in that figure. 


When a new session is activated, it comes up 
in-brackets with the resources manager on the 
primary side of the session having control of 
the session. This is true even if = the 
resources manager on the secondary side of 
the session was the one that issued the ACTI- 
VATE_SESSION record that caused the session 
to be activated. Upon receipt of a positive 


_ VATE_SESSION_RSP (or SESSION_ACTIVATED). 


ACTIVATE_SESSION_RSP (or SESSION_ACTIVATED in 
the case of activation by the partner LU), RM 
creates and initializes an SCB based on the 
information carried in the § ACTI- 


If the newly activated session is a primary 


half-session, RM determines if any requests 
are waiting to be serviced. If LU-LU verifi- 
cation is not active and a request is waiting 
(1), RM uses the new session to service the 
request and sends a SESSION_ALLOCATED record 
to presentation services. If LU-LU verifica- 
tion is active and a request is waiting (2), | 
RM will generate and send to the half-session © 
an ENCIPHERED_RD2 record containing == an 
FMH-12. Parameters within the ENCIPHERED_RD2 
record inform HS not to end the bracket nor 
yield control of the session. RM then uses 
the new session to service the request and 
sends a SESSION_ALLOCATED record to presenta- 
tion services. If no requests are waiting 
and LU-LU verification is active (3), RM will 
generate and send to the half-session an 
ENCIPHERED_RD2 record containing an FMH-12 
and parameters that inform the half-session 
to relinquish control of the session and end 
the bracket. If no requests are waiting and 
LU-LU verification is not active (4), RM 
sends a YIELD_SESSION record to HS, thus 
yielding its right to use the session and 
ending the bracket. 


The resources manager at the partner LU (sec- 
ondary half-session) is notified of the ses- 
sion activation by a SESSION_ACTIVATED record 
from its LNS component. If LU-LU verifica- 
tion is active, the secondary LU's resources 
manager will await receipt of a SECURI- 
TY_HEADER record that contains the FMH-12. 
When the SECURITY_HEADER record is received 
and verified by the secondary LU, normal 
processing continues. 
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Figure 3-12. Decreasing the Number of Sessions 


CHANGING THE MAXIMUM SESSION LIMIT 


The MODE control block (see page A-3) con- 
tains several session limit fields. These 
fields limit the number” and polarity 
(first-speaker or bidder) of sessions that 
this LU can have with the partner LU and mode 
name represented by the MODE control block. 
The limit fields include: 


@®  SESSION_LIMIT—limit on the total number 
of sessions 


e MIN_CONWINNERS LIMIT—Limit on the number 
of bidder sessions. The SESSION_LIMIT 
less the number of bidder sessions must 
be greater than or equal to 
MIN_CONWINNERS LIMIT. 


@ MIN_CONLOSERS LIMIT—limit on the number 
of first-speaker sessions. The SES- 
SION_LIMIT less the number of 
first-speaker sessions must be greater 
than or equal to MIN_CONLOSERS_LIMIT. 


@ AUTO_ACTIVATIONS_LIMIT—the number 9 of 
session that are activated independent of 
demand. All such sessions will be 
first-speaker sessions. 


The change number of sessions (CNOS) trans- 
action program ("Chapter 5.4. Presentation 
Services--Control-Operator Verbs") can cause 
the session limits to change. The CNOS 
transaction programs at the two LUs come to 
an agreement on what the new session limits 
are to be via an exchange of Change Number of 
Sessions GDS variables (see "Appendix H. FM 
Header and LU Services Commands"). After an 
agreement on the new session limits § is 
reached, the CNOS transaction program sends a 
CHANGE_SESSIONS record to its resources man- 
ager. The CHANGE_SESSIONS notifies the 
resources manager that a change in the ses- 
sion limits has occurred. 


If the new session limits imply that new ses- 
sions may be activated, RM determines if 
there are any waiting requests. If so, it 
creates multiple ACTIVATE_SESSION records, 
one for each waiting request, and sends them 
to LU network services (see "Activating a New 
Session" on page 3-13 for more on session 
activation). The resources manager does not, 
however, request that more sessions be acti- 
vated than can be accommodated by the new 
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session limits. The excess requests are 
retained for later processing. 


The resources manager makes certain that at 
least a rmmber of sessions equal to the 
AUTO_ACTIVATIONS_LINIT are active. After 
this number of sessions is active, RM will 
request session activation only to satisfy 
waiting requests. For example, if 
AUTO_ACTIVATIONS_LIMIT = 2 and five requests 
are waiting, but the new session limits imply 
that seven sessions could be concurrently 
active, the resources manager sends to LU 
network services only five ACTIVATE_SESSION 
records. 


When the session limits are decreased, one of 
the LUs is designated as being "responsible' 
for deactivating sessions, as necessary to 
satisfy the new session limits. 
CHANGE_SESSION.RESPONSIBLE is set to YES if 
the resources manager is responsible to deac- 
tivate sessions. 


The resources manager computes ai TERMI- 
NATION_COUNT, which is the number of sessions 
that this LU is responsible to deactivate. 
RM chooses sessions to deactivate from the 
pool of free sessions with that LU and mode 
name, sending a BIS_RQ record on each of the 
sessions that it has chosen and removing the 
entry for that session from the free session 
pool. The BIS_RQ is sent to inform the 
receiving resources manager that the sending 
RM will not initiate any subsequent brackets, 
and is sent only ohile the = sending 
half-session is between brackets. When RM 
receives a BIS_REPLY record in response to 
its BIS.RQ, it decrements the TERMI- 
NATION_COUNT and sends to LU network services 
a DEACTIVATE_SESSION record for that session. 


for sending 


LU network services then performs the normal 
UNBIND protocols. A BIS_RQ-BIS REPLY 
exchange precedes a normal UNBIND (i.e.» 
types X'O1l', X'02', or X'03'). See Fig- 
ure 3-12 on page 3-15 for the flows involved. 


If not enough free sessions can be deacti- 
vated to bring the TERMINATION_COUNT to 0, RM 
waits for sessions that are currently in use 
to become free before it sends any more 
BIS R@Qs. 


The value of the DRAIN_SELF field in the MODE 
control block determines whether RM will send 
BIS RQ immediately when a session becomes 
free. If DRAIN_SELF = NO (i.e., waiting ses- 
sion allocation requests are not to be satis- 
fied before session deactivation), RM will 
send BIS _RQ as soon as a session becomes 
free. If DRAIN SELF = YES (Ci.e., waiting 
session allocation requests are to be satis- 
fied before session activation), RM will send 
BIS_RQ only if there are no waiting requests 
when the session becomes free. In the same 
way, ORAIN_SELF determines when BIS_REPLY is 
sent in reply to a BIS_RQ@ from the partner 
LU; i.e., if DRAIN_SELF = NO, BIS_REPLY is 
sent immediately; otherwise, BIS_REPLY is 
sent only when there are no waiting requests. 


The LU control operator may also explicitly 
request that a session be activated or deac- 
tivated, RM is notified of these 
control-operator requests with an 
RM_ACTIVATE_SESSION or RM_DEACTIVATE_ SESSION 
record. The resources manager is responsible 
ACTIVATE_SESSION or DEACTI- 
VATE_SESSION records (preceded by the usual 
BIS_RQ-BIS_REPLY exchange for normal deacti- 
vation) to LU network services to satisfy 
these control-operator requests. 
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Figure 3-13. Session-Outage Actions 


SESSION OUTAGE 


An active session between two LUs sometimes 
fails. The session outage could be caused by 
a failure of one or both of the LUs, or by a 
failure in the path between the LUs. In the 
event of a session outage, the resources man- 
ager receives a SESSION_DEACTIVATED(REASON = 
SON) from LU network services. If the ses- 
sion is being used by a conversation, RM 


CREATION AND TERMINATION OF PRESENTATION SERVICES 


The resources manager is responsible for cre- 
ating and terminating instances of presenta- 
tion services. (Presentation services, in 
turn, is responsible for starting up and tak- 
ing down the transaction program with which 
it is to be associated.) The resources man- 
ager creates a new instance of presentation 
services on receipt of an ATTACH_HEADER 
record. Along with creating a new PS proc- 
ess, RM at this time also creates a new TCB 
and RCB, and informs PS of the HS_ID of the 


sends a CONVERSATION_FAILURE record to pres- 
entation services to informa it of the outage, 
and receives frow PS a DEALLOCATE_RCB at some 
point. Regardless of whether the session is 
in use, RM destroys the associated SCB. Fig- 
ure 3-13 illustrates the  session-outage 
flows. 


half-session over which the initial conversa- 
tion is flowing. Finally, it sends to pres- 
entation services the FMH-5 contained in the 
ATTACH_HEADER record, and the I0s of the new 
TCB and RCB. 


When a transaction program finishes its proc- 
essing, presentation services notifies the 
resources manager via a TERMINATE_PS record. 
RM destroys the PS process and the associated 


| TCB. 
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HIGH-LEVEL PROCEDURES 


RM 


FUNCTION: This process initializes RM_PROCESS_DATA and receives all input to the 
resources manager and routes the input to the appropriate procedure for proc- 
essing. 


INPUT: RM_RECORD is received asynchronously from network services (LNS), half-session 
(HS), presentation services (PS), and the undefined protocol machine, UPM_IPL. 


OUTPUT: Refer to the procedures that are called from this process for the outputs 
resulting from records received from other processes. 


NOTE: - UPM_IPL 1s an implementation-defined process. It sends an Attach to RM when a 
transaction program is to be started locally. 


Referenced procedures, FSMs, and data structures: 


PROCESS _LNS_ TO_RM_RECORD page 3-20 
PROCESS_HS_TO_RM_RECORD page 3-19 
ATTACH_PROC page 3-27 
PROCESS_PS_TO_RM_RECORD page 3-21 


Do forever: 
Receive a record. 
Select based on the sender of the record: 
When LNS 
Call PROCESS_LNS_TO_RM_RECORD( record received) (page 3-20). 
When HS | 
» Call PROCESS _HS_TO_RM_RECORD(record received) (page 3-19). 
When UPM_IPL 
Call ATTACH_PROC(record received, UPM) (page 3-27). 
When PS 
Cala PROCESS _PS_TO_RM_RECORD(record received) (page 3-21). 
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PROCESS_HS_TO_RM_RECORD 
PROCESS_HS_TO_RM_RECORD 


FUNCTION: This procedure routes records received from HS to the appropriate procedure 
for processing. 


INPUT: The current record from a half-session 


OUTPUT: Refer to the procedures that are called from this process for the specific 
outputs. 


NOTES: 1. If an SCB_ is not found with an HS_ID matching HS_TO_PS_RECORD.HS_ID, the 
record is discarded. This could occur, for example, if session outage 
occurred before RM had processed all the records from that half-session. 


If #FSM_BIS indicates that the session is closed, the record is discarded. 
This could occur, if the resources manager in the partner LU sends a -RTR_RSP 
after having sent BIS_REPLY. 


Referenced procedures, FSMs,», and data structures: 


BID_PROC page 3-30 
BID_RSP_PROC page 3-32 
ATTACH_PROC page 3-27 
FREE_SESSION_PROC - page 3-44 
RTR_RQ_PROC page 3-50 
RTR_RSP_PROC page 3-51 
BIS _RQ_PROC page 3-36 
SECURITY_PROC page 3-52 
BIS_REPLY_PROC page 3-35 
FSM_BIS_BIDDER | page 3-70 
FSM_BIS_FSP page 3-71 
HS _TO_RM_RECORD page A-13 
SCB page A-9 


If no SCB has SCB.HS_ID = HS_TO_PS_RECORD.HS_ID then 
Discard the HS_TO_RM_RECORD (see Note 1). 
Else 
If the state of #FSM_BIS # CLOSED (page 3-70) then 
Select based on HS_TO_RM_RECORD type: 
When BID 
Call BID_PROC(HS_TO_RM_RECORD) (page 3-30). 
When BID_RSP 
Call BID_RSP_PROC(HS_TO_RM_RECORD) (page 3-32). 
When ATTACH_HEADER 
Call ATTACH_PROC(HS_TO_RM_RECORD, HS) (page 3-27). 
When FREE_SESSION 
Call FREE_SESSION_PROC(HS_TO_RM_RECORD) (page 3-44). 
When RTR_RQ 
Call RTR_RQ_PROC(HS_TO_RM_RECORD) (page 3-50). 
When RTR_RSP 
Call RTR_RSP_PROC(HS_TO_RM_RECORD) (page 3-51). 
When BIS_RQ 
Call BIS_P@_PRUC(HS_TO_RM_RECORD) (page 3-36). 
Mveit GIS _REPLY 
Call BIS_REPLY_PROC(HS_TO_RM_RECORD) (page 3-35). 
When SECURITY_HEADER 
Call SECURITY_PROC(HS_TO_RM_RECORD) (page 3-52). 
Else 
Do nothing (see Note 2). 
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PROCESS_LNS_TO_RM_RECORD 


PROCESS_LNS_TO_RM_RECORD 


FUNCTION: This procedure routes records received from NS to the appropriate procedure 
for processing. 


INPUT: LNS_TO_RM_RECORD, the current record from LNS 


OUTPUT: Refer to the procedures that are called from this procedure for the specific 
outputs. 


Referenced procedures, FSMs, and data structures: | 
ACTIVATE_SESSION_RSP_PROC page 3-23 


SESSION_ACTIVATED_PROC - | page 3-57 
SESSION_DEACTIVATED_ PROC page 3-58 
CTERM_DEACTIVATE_SESSION_PROC | : page 3-40 
LNS_TO_RM_RECORD page A-19 


Select based on LNS_TO_RM_RECORD type: 
When ACTIVATE_SESSION_RSP 
Call ACTIVATE_SESSION_RSP_PROC(LNS_TO_RM_RECORD) (page 3-23). 
When SESSION_ACTIVATED 
Call SESSION_ACTIVATED_PROC( LNS_TO_RM_RECORD) (page 3-57). 
When SESSION_DEACTIVATED 
Call SESSION_DEACTIVATED_ PROC( LNS_TO_RM_RECORD) (page 3-58). 
When CTERM_DEACTIVATE_SESSION 
Call CTERM_DEACTIVATE_SESSION_PROC( LNS_TO_RM_RECORD) (page 3-40). 
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PROCESS_PS_TO_RM_RECORD 


FUNCTION: This procedure routes records received from presentation services to the 
appropriate procedure for processing. 


INPUT: The current record from presentation services 


OUTPUT : Refer to the procedures that are called from this procedure for the specific 
outputs. 


Referenced procedures, FSMs, and data structures: 


ALLOCATE_RCB_PROC page 3-24 
GET_SESSION_PROC page 3-45 
CHANGE_SESSIONS_ PROC page 3-37 
RM_ACTIVATE_SESSION_PROC page 3-48 
RM_DEACTIVATE_SESSION_PROC page 3-49 
UNBIND_PROTOCOL_ERROR_PROC page 3-65 
PS page 5.0-5 
RCB page A-7 
TCB page A-10 
PS_TO_RM_RECORD page A-25 
DEALLOCATE_RCB page A-26 
RCB_DEALLOCATED page A-33 


Select based on PS_TO_RM_RECORD type: 
When ALLOCATE_RCB 
Call ALLOCATE_RCB_PROC(PS_TO_RM_RECORD) (page 3-24). 
When GET_SESSION 
Call GET_SESSION_PROC(PS_TO_RM_RECORD) (page 3-45). 
When DEALLOCATE_RCB 
Discard the RCB with RCB.ID equal to DEALLOCATE_RCB.RCB_ID. 
Build and send an RCB_DEALLOCATED record to PS (Chapter 5.0). 
When TERMINATE_PS 
~ Discard the TCB and PS corresponding to TERMINATE_PS.TCB_ID. 
When CHANGE_SESSIONS 
Call CHANGE_SESSIONS PROC(PS_TO_RM_RECORD) (page 3-37). 
When RM_ACTIVATE_SESSION 
Call RM_ACTIVATE_SESSION_PROC(PS_TO_RM_RECORD) (page 3-48). 
When RM_DEACTIVATE_SESSION 
Call RM_DEACTIVATE_SESSION_PROC(PS_TO_RM_RECORD) (page 3-49). 
When UNBIND_PROTOCOL_ERROR 
Call UNBIND_PROTOCOL_ERROR_PROC(PS_TO_RM_RECORD) (page 3-65). 
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ACTIVATE_NEEDED_SESSIONS 


FUNCTION: This procedure activates sessions as required by change-number-of-sessions 
7 zy 4 ~ (CNOS). processing: | . 


: Sessions are activated so as to satisfy the waiting requests, but not to 
exceed the (LU, mode) session limit. If all waiting requests are satisfied, 
additional sessions are activated to bring the number of sessions up to the 
minimum of the MODE.AUTO_ACTIVATIONS_LIMIT and MODE.MIN_CONWINNERS LIMIT. 


INPUT: LU_NAME and MODE _NAME, the LU name and mode name, respectively, of the partner 
ee ; LU 


OUTPUT: Zero or more ACTIVATE_SESSION records to LNS 


Referenced procedures, FSMs, and data structures: 


SESSION_ACTIVATION_POLARITY page 3-57 
SEND_ACTIVATE_SESSION page 3-52 
LU_NAME page 3-74 
MODE_NAME page 3-74 
ACTIVATE_SESSION page A-31l 
MODE | page A-3 


Get addressability to the MODE control block associated with LU_NAME and 
MODE_NAME. 

Do while the number of waiting requests for sessions to (LU_NAME, MODE_NAME ) 
is less than MODE.PENDING_SESSION_COUNT, and the polarity returned by 
SESSION_ACTIVATION_POLARITY(LU_NAME, MODE_NAME) (page 3-57) # NONE. 

If polarity = FIRST_SPEAKER then 
Call SEND_ACTIVATE_SESSION( LU_NAME, MODE_NAME, FIRST_SPEAKER) (page 3-52) 
to send an ACTIVATE_SESSION record to LNS. 
Else (BIDDER) 
Call SEND_ACTIVATE_SESSION( LU_NAME, MODE_NAME, BIDDER) (page 3-52). 

Do while the minimum of (MODE.AUTO_ACTIVATIONS_LIMIT, MODE.MIN_CONWINNERS_LIMIT). < 
(MODE .ACTIVE_CONWINNERS_COUNT + MODE.PENDING CONWINNERS_ COUNT), and the polarity 
returned by SESSION_ACTIVATION_POLARITY( LU_NAME, MODE_NAME) (page 3-57) = FIRST_SPEAKER. 

Call SEND_ACTIVATE_SESSION( LU_LNAME, MODE_NAME, FIRST_SPEAKER) (page 3-52). 
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ACTIVATE_SESSION_RSP_PROC 
ACTIVATE_SESSION_RSP_PROC 


This procedure handles the processing of the response to a previously issued 
ACTIVATE_SESSION request. 


The session counts in the appropriate MODE entry are updated and further proc- 
essing is invoked depending on the response type. 


ACTIVATE_SESSION_RSP from LNS 


SESSION_ALLOCATED to PS, or no output 


The pending activation will not be found if RM had previously requested deac- 
tivation of the pending session as a result of change-nunber-of-sessions proc- 
essing. In this case, no processing of the ACTIVATE_SESSION_RSP is performed, 
since the session is being deactivated. 


Referenced procedures, FSMs, and data structures: 


SUCCESSFUL_SESSION_ACTIVATION page 3-63 
UNSUCCESSFUL_SESSION_ACTIVATION page 3-66 
ACTIVATE_SESSION_RSP page A-20 
MODE page A-3 
MODE_NAME page 3-74 


If there exists a pending activation with a correlator equal to 
ACTIVATE_SESSION_RSP.CORRELATOR then 
Get addressability to the MODE control block associated with the LU and 
mode name of the pending-active session. 
Decrement MODE.PENDING CONWINNERS_COUNT or MODE.PENDING CONLOSERS_COUNT by 1, 
as appropriate to the session polarity. 
Decrement MODE.PENODING SESSION_COUNT by 1. 
If ACTIVATE _SESSION_RSP.TYPE = POS Then 

Increment MODE.ACTIVE_CONWINNERS COUNT or MODE.ACTIVE_CONLOSERS COUNT by 1, 
as appropriate to the session polarity. 

Increment MODE .ACTIVE_SESSION_COUNT by 1. 

Call SUCCESSFUL_SESSION_ACTIVATION(LU name of pending activation, 
MODE_NAME of pending activation, 
ACTIVATE_SESSION_RSP.SESSION_INFORMATION) (page 3-63). 

Else (negative response) 

Call UNSUCCESSFUL_SESSION_ACTIVATION( LU name of pending activation, 
MODE_NAME of pending activation, 

ACTIVATE_SESSION_RSP.ERROR_TYPE) (page 3-66). 
Else 
Do nothing (see Note). 
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ALLOCATE_RCB_PROC 


This procedure handles the allocation of resource control blocks (RCBs). 


This procedure first creates the RCB_ALLOCATED record, which is sent to 
PS.CONV to inform it of the outcome of the ALLOCATE_RCB request, and initial- 
izes the fields of the record. It then calls the appropriate procedure, 
depending upon the ALLOCATE_RCB parameter settings. The procedure that this 
procedure calls changes the setting of some of the RCB_ALLOCATED fields before 
the RCB_ALLOCATED is finally sent to PS.CONV (Chapter 5.1) 


ALLOCATE_RCB 
RCB_ALLOCATED to PS 


When ALLOCATE_RCB.IMMEDIATE_SESSION is set to YES, RM is to check to see if a 
first-speaker half-session is currently available for use. If such a session 
is available, the RCB_ID is passed to PS.CONV and the request completes suc- 
cessfully. (If IMMEDIATE_SESSION is set to NO, PS.CONV sends a separate 
GET_SESSION request to RM to request that a half-session be allocated to a 
particular conversation resource. ) 


Referenced procedures, FSMs, and data structures: 


TEST_FOR_FREE_FSP_SESSION page 3-65 
~ CREATE_ RCB ? page 3-39 
PS page 5.0-5 
ALLOCATE _RCB | / page A-25 
RCB_ ALLOCATED eee page A-32 


Initialize an RCB_ALLOCATED record with RETURN_ CODE set to OK = 
RCB_ID set to a null value. | 
If ALLOCATE _RCB.IMMEDIATE_SESSION is set to YES then 
Call TEST_ FOR_FREE_FSP_SESSION( ALLOCATE _RCB, RCB_ALLOCATED) (page 3-65). 


Else 


Call CREATE_RCBCALLOCATE_RCB, RCB_ ALLOCATED) (page 3-39). 
Send the RCB_. ALLOCATED record to PS.CONV (Chapter 5.1). 
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ATTACH_CHECK 


FUNCTION: This procedure checks particular fields of the passed ATTACH HEADER for valid- 


ity. (PS is responsible for checking the remaining fields. ) 


INPUT: ATTACH_HEADER 
OUTPUT : X'00000000', if no error; or sense data returned by ATTACH _LENGTH_CHECK; or 
data returned by ATTACH_SECURITY_CHECK; or one of the following sense data: 
X'Q80F6051'. Security Not Valid 
X'084B6031' TP Not Available--Retry Allowed 
X'084C0000' TP Not Available--No Retry 
X%'1008600B' Unrecognized FMH Command 
X'10086021' TP Name Not Recognized 
X'10086040' Invalid Attach Parameter 
X°10086041' Sync Level Not Supported 


Referenced procedures, FSMs, and data structures: 


ATTACH_LENGTH_ CHECK page 3-26 
ATTACH_SECURITY_CHECK page 3-29 
ATTACH_HEADER page A-13 


Call ATTACH_LENGTH_CHECK( ATTACH _HEADER.HEADER) (page 3-26) to determine whether any 
FMH-5 fields have an invalid length. 
If ATTACH_LENGTH_CHECK indicates that a field length is invalid then 
Return with the sense data provided by ATTACH_LENGTH_CHECK. 
Select based on the Command field of the FMH-5; 
When Attach 
If the transaction program specified in the Attach exists at this LU then 
Select based on the syne level specified in the Attach: 
(Optional receive check--the sync level support specified 
in the FMH-5 must be compatible with the sync level 
supported by the partner LU). 
When None or Confirm 
Do nothing. (ALI LUs support syne level Confirs.) 
When Confirm, Syne Point, and Backout 
If the sessions to the remote LU do not support Confirm, Sync Point, 
and Backout then 
Return with sense data X'10086040' (Invalid Attach Parameter ). 
If the sync level specified in the Attach is not supported by 
the transaction program then 
Return with sense data X'10086041' (Syne Level Not Supported). 
If the transaction program is temporarily disabled then 
Return with sense data X'084B6031' (TP Not Available--Retry Alloned). 
If the transaction program is permanently disabled then 
Return with sense data X'084C0000' (TP Not Available--No Retry). 
If the transaction program requires security parameters in the Attach and 
the sending LU is not permitted by this LU to send them then 
Return with sense data X'080F6051' (Security Not Valid). 


Call ATTACH _SECURITY_CHECK(ATTACH_ HEADER) (page 3-29) to check that all security 


requirements are met. 
If ATTACH _SECURITY_CHECK indicates a security violation then 
Return with the data provided by ATTACH _SECURITY_CHECK. 
Else | 
Return with sense data X'10086021' (TP Name Not Recognized). 
Otherwise 
Return with sense data X'1008600B' (Unrecognized FMH Command). 
Return with sense data X'00000000' indicating no error. 
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ATTACH_LENGTH_CHECK 


This procedure checks the length fields in the passed Attach for validity. 


An FMH-5 Attach header (see “Appendix H. FM Header and LU Services Commands" ) 


Sense data reflecting the result of the length checks. One of the following 
sense data is returned: 


X'00000000' No error 

X'10086000' FMH Length Not Correct 

X' 10086005 ' Access Security Information Length Invalid 
X'10086009' Invalid Parameter Length , 

X'10086011' Invalid Logical Unit of Hork 


The total length of the Attach can be greater than the sum of the lengths of 
the currently defined fields, to allow for the addition of new Attach fields. 


Set OFFSET to 5 (offset of Fixed Length Parameters field in Attach). 
If the Atiach length < OFFSET then 
Return with X'10086000' (FMH Length Not Correct). 
If the value of the Fixed Length Parameters field < 3 then 
Return with X'10086009' (Invalid Parameter Length). 
Set OFFSET to OFFSET + the value of the Fixed Length Parameters field + 1 
(offset of TP name Length field). 
If the Attach length £ OFFSET then 
Return with X'10086000' (FMH Length Not Correct). 
Set OFFSET to OFFSET + the value of the TP name Length field + 1 
(offset of Access Security Information Length field). 
Select based on the following comparisons: 
When the Attach length < OFFSET 
Return with X'10086000' (FMH Length Not Correct). 
When the Attach length = OFFSET 
Return with X'00000000' (Access Security Information and following fields nat present). 
When the Attach length > OFFSET (Access Security Information present) 
Do nothing. 
If the value of the Access Security Information Length field > 0 then 
(Access Security information is present) 
If the Access Security subfield length > the allowed length (12) or 
more than three Access Security subfields are present or 
the sum of the lengths of the Access Security subfields does not equal 
the total length of the Access Security Information field then 
Return with X'10086005' (Access Security Information Length Invalid). 
Set OFFSET to OFFSET + the value of the Access Security Information Length field + 1 
(offset of LUW Identifier Length field). 
Select based on the following comparisons: 
When the Attach length < OFFSET 
Return with X'10086000' (FMH Length Not Correct). 
When the Attach length = OFFSET 
Return with X'00000000' (LUN Identifier and following fields not present). 
When the Attach length > OFFSET (LUN Identifier present) 
Do nothing. 
If the value of the LUW Identifier Length field > 0 then (LUW Identifier present) 
If the value of the LUW Identifier Length field < 16 or > 26 then 
Return with X°'10086011' (Invalid Logical Unit of Work). 
If the value of the LUW Identifier Length field * the value of the LUN Identifier 
LU name Length field + 9 then 
Return with X'10086011' (Invalid Logical Unit of Work). 
Set OFFSET to OFFSET + the value of the LUW Identifier ee field + 1 
(offset of byte following ATTACH). 
If the Attach length < OFFSET then 
Return with X'10086000' (FMH Length Not Correct). | 
Else 


Return with X'00000000' (All length fields in Attach are valid). 
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ATTACH_PROC 


FUNCTION: This procedure performs Attach processing. 


If the Attach FM header was sent by HS, this procedure checks to see if the 
session is already in use. If the session 1s not in use, the appropriate sub- 
routines are called to check certain fields in the Attach FM header for valid- 
ity. If a partner-LU protocol error is found, the appropriate procedure is 
called to deactivate the session; otherwise, a new conversation with a new PS 
process is started. 


INPUT: ATTACH_HEADER and an indicator stating whether the Attach was sent by HS or 
UPM_IPL 


OUTPUT: None 


NOTES: 1. RM does not generate a +RSP(Attach). HS does generates a positive BID_RSP, 


however; so the RM that sent the Attach gets a positive response to the 
Attach. 


If the state of #FSM_SCB_STATUS is PENDING_ATTACH, the half-session is 
first-speaker and a prior BID was received, or the half-session 1s a secondary 
first-speaker or bidder and has just been activated. Although RM can bid with 
an Attach, HS on the receive side of the half-session converts’ the 
BID_WITH_ATTACH record into separate BID and ATTACH_HEADER records. When RM 
receives the BID, if the half-session 1s not in use, it changes the status of 
the half-session to PENDING_ATTACH. 


This protocol error occurs, for example, when the first-speaker half-session 
sends an Attach FM header after having positively responded to a Bid from the 
bidder half-session, or when an Attach FM header is received § for which there 
was no prior Bid. 


Referenced procedures, FSMs, and data structures: 


RM_PROTOCOL_ERROR page 3-49 
ATTACH_CHECK | page 3-25 
PS _CREATION_PROC page 3-47 
COMPLETE_HS_ATTACH page 3-38 
PS page 5.0-5 
FSM_SCB_STATUS._BIDDER page 3-68 
FSM_SCB_STATUS_FSP page 3-69 
ATTACH_HEADER page A-13 
ATTACH_RECEIVED page A-32 
TCB_ID page 3-74 
RCB_ID page 3-74 
SCB page A-9 


Set TCB_ID and RCB_ID to null. 
Select based on the process that sent the Attach: 
When HS 
Find the SCB corresponding to the HS process that sent the Attach. 
If the state of #FSM_SCB_STATUS # PENDING_ATTACH (page 3-67) then 
Call RM_PROTOCOL_ERROR(SCB.HS_ID, X'?9°30000') (o>r¢2 2-45 and see Note 3). 
Else 
Call ATTACH_CHECK(ATTAC.1_HEADER) (page 3-25) to determine if the 
Attach contaifs any errors. 
Ti AVTACH_CHECK indicates an LU security protocol error then 
Call RM_PROTOCOL_ERROR(SCB.HS_ID, X'080F6051') (page 3-49) 
Else 
Select based on the Command field of the Attach: 
When Attach (start a new conversation) 
Call FS_CREATION_PROC(ATTACH_HEADER, ATTACH_SENDER, TCB_ID, RCB_ID) 
(page 3-47). 
Call COMPLETE_HS_ATTACH( ATTACH _HEADER.HS_ID, RCB_ID, TCB_ID) (page 3-38). 
Create an ATTACH_RECEIVED record with ATTACH_RECEIVED.TCB_ID and 
ATTACH_RECEIVED.RCB_ID initialized to TCB_ID and RCB_ID,» respectively; 
the SENSE_CODE field initialized to the sense data (if any) set 
by ATTACH _CHECK; and the FMH_5 field initialized to the 
Attach FM header. 
Send the ATTACH_RECEIVED record to PS (Chapter 5.0). 
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When UPM 
Call PS_CREATION_PROC( ATTACH_HEADER, ATTACH_SENDER, TCB_ID, RCB_ID) (page 
Create an ATTACHED_RECEIVED record with ATTACH_RECEIVED.TCB_ID and 
ATTACH_RECEIVED.RCB_ID initialized to TCB_ID and RCB_ID, respectively; 
the SENSE_CODE field initialized to X%*'00000000'; 
and the FMH_5 field initialized to the Attach FM header. 
Send the ATTACH RECEIVED record to PS (Chapter 5.0). 
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ATTACH_SECURITY_CHECK 
ATTACH_SECURITY_ CHECK 


FUNCTION: This procedure performs all security checks on an incoming Attach. 


INPUT: The received ATTACH_HEADER that contains the FMH-5 (Attach) (see "Appendix H. 
FM Header and LU Services Commands") 


OUTPUT: A code or sense data indicating the result of the security check: 


FFFFFFFF local indication of a partner-LU security protocol error 

10086040 an Attach parameter is present that is not authorized by the BIND 
security indicators 

080F6051 a remote TP security error is found 

00000000 the Attach passes all security checks 


NOTES: 1. AL1 checks within this procedure are required receive checks for implementa- 
tions that support the conversation-level security option. 


2. If the use of profiles is not supported and one is received, it is ignored. 
If the use of profiles is supported, the option of requiring profiles on every 
Attach verses only requiring profiles on Attach to specific resources is 
installation-defined. If a profile is required on every attach, connectivity 
problems with LUs that can not send profile may result. 


An unauthorized combination of user ID and profile means that the user that 
provides the profile is not permitted to supply that profile. Profiles are 
installation defined at the receiver of the Attach. Profiles assigned to spe- 
cific user IDs are installation defined at the receiver of the Attach. The 
use and interpretation of profiles is not limited to access to secure trans- 
action programs. Profiles may be used to restrict access to resources in 
implementation and installation defined ways (e.g., as group IDs). 


If the Attach indicates End User Already Verified and 
this LU does not accept an Already Verified indication in an Attach from the partner LU then 
Return with sense data X'10086040' (Invalid Attach Parameter). 
If the Attach contains security parameters and 
this LU does not accept security parameters in an Attach from the partner LU then 
Return with sense data X'10086040' (Invalid Attach Parameter). 
If the target transaction program requires security parameters in an Attach and 
the Attach does not contain security parameters then 
Return with sense data X'080F6051' (Security Not Valid). 
If the Attach contains no security parameters then 
Return with code X'00000000' (no security protocol violation). 
If there are multiple security subfields of the same type in the Attach then 
Return with code X'FFFFFFFF' (partner-LU security protocol error). 
If there is a security subfield of an unrecognized type then 
Return with code X'FFFFFFFF' (partner-LU security protocol error). 
If the Attach contains a profile and does not contain a user ID then 
Return with sense data X'080F6051' (Security Not Valid). 
If the Attach contains a password and does not contain a user ID then 
Return with sense data X'080F6051' (Security Not Valid). 
If the Attach indicates end user not already verified and 
the Attach contains a user ID and does not contain a password then 
Return with sense data X'O80F6051' (Security Not Valid). 
If the Attach indicates end user not already verified and 
the Attach contains an unauthorized combination of user ID and profile or (see note 2) 
the Attach contains an invalid combination of user ID and password then 
Return with sense data X'080F6051' (Security Not Valid). 
If the Attach indicates end user is already verified and 
‘ the Attach does not contain a user ID or the Attach does contain a password then 
Return with code X'FFFFFFFF' (partner-LU security protocol error). 
If there is limited access to the target transaction program, which is based upon the Attach's 
user ID and/or profile of the Attach sender then 
If the user ID and/or profile is not permitted access 
to this transaction program then 
Return with sense data X'080F6051' (Security Not Valid). 
Return with code X'00000000' (Attach passes all security checks). 
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BID_PROC 


FUNCTION: This procedure handles bids - for the use of sessions. : 


This procedure first hacks whether the bid should be rejected because the 
local operator has reset the session limit to 0 with no draining of the part- 
ner LU's requests, and this LU does not support parallel sessions to the part- 
ner LU. In this case, a. -BID_RSP(088B) ‘is sent to HS. The -BID_RSP(088B) can 
be sent even if the partner LU is ‘the ‘first speaker. | 


If -BID_RSP(088B) is not sent, the eee ee checks to see if the requested 
session is free. If so, it removes the session from the free-session pool. 
and sends a_ positive BID_RSP to HS. Tf: the session is not free, it sends a 
negative BID_RSP to HS. 7 ~ - 


An implementation may allow a chermacticn program to reserve a session for its 
own use before the conversation begins. If a session has been reserved, a 
negative BID_RSP is sent to HS even though a conversation has not been started 
on the session. Since the transaction program might never use the reserved 
session (e. Q.» the transaction program terminates abnormally before the con- 
versation is started), the. negative response carries an 0814 sense code 
(Bracket Bid Reject--RTR Forthcoming) to allow the session to be freed, in 
case the reserved session is not needed by a conversation. Reserving a ses- 
sion is implementation dependent and is not shown here. 


INPUT : BID 
OUTPUT : BID_RSP to HS. The RTI field of the BID_RSP is set to either POS or NEG. 


NOTES: 1. RM can bid with an Attach. However, when HS on the receive side of the con- 
versation gets the BID_LWITH_ATTACH record, it splits it into two records: a 
BID and a separate ATTACH_HEADER. Therefore, when RM receives a bid for a 
session, it will always be via a BID record. When RM receives” the 
ATTACH_HEADER, the state of #FSM_SCB_STATUS is always PENDING ATTACH. 


If RM has issued an RTR to the partner LU and has received a positive response 
to the RTR, the HS_ID of the session over which the RTR flowed will not be 
free when the BID is received. When RM issued the RTR, it removed that ses- 
sion from the free-session pool. 


Referenced procedures, FSMs, and data structures: 


RM_PROTOCOL_ERROR page 3-49 
HS page 6.0-3 
FSM_SCB_STATUS_BIDDER page 3-68 
FSM_SCB_STATUS_FSP page 3-69 
FSM_BIS_BIDDER page 3-70 
FSM_BIS_FSP page 3-71 
BID page A-14 
MODE page A-3 
BID_RSP page A-28 
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If the state of #FSM_BIS is BIS_RCVD (page 3-70) then 

Call RM_PROTOCOL_ERROR(BID.HS_ID, X'20080000') (page 3-49) 

(optional receive check, No Begin Bracket). 
Else 

Get addressability to the MODE control block associated with the LU and 
mode name for this session. 

If parallel sessions are not supported to the partner LU and 
MODE.SESSION_LIMIT = 0 and MODE.DRAIN_PARTNER = NO and the state of 
#FSM_BIS (page 3-70) is BIS_SENT then 

Create a BID_RSP record with RTI set to NEG and SENSE_CODE set to 
X'088B0000' and send it to HS (Chapter 6.0). 
Else 
If the state of #FSM_SCB_STATUS is FREE (page 3-67) then 
Call #FSM_SCB_STATUS(R, BID, UNDEFINED) (page 3-67) 
(State of #FSM_SCB_STATUS is PENDING_ATTACH). 
Remove the session from the free-session pool. 
Create a BID_RSP record with RTI set to POS and SENSE_CODE set to 
X'00000000' and send it to HS (Chapter 6.0). 
Else 
If this is a first-speaker session then 
Create a BID_RSP record with RTI set to NEG and SENSE_CODE set to 
X'08130000' or X'08140000' (Cimplementation-dependent choice) 
and send it to HS (Chapter 6.0). 
If SENSE_CODE was X'08140000' then 
Remember that this LU owes RTR to its partner (RTR must be sent to the 
partner LU before it can bid again for this session). 
Else 
Call RM_PROTOCOL_ERROR(BID.HS_ID, X'20030000') (page 3-49) 
(optional receive check, Bracket Error). 
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BID_RSP_PROC 


FUNCTION: 


INPUT: 
OUTPUT : 


NOTES: 


1. 


This procedure handles the processing of responses to bids for the use of 
half-sessions. , 


A bid response is usually sent to the resources manager in response to a pre- 
vious bid for a bidder half-session. In this case, when the input is a posi- 
tive BID_RSP, this procedure calls the appropriate subroutines to cause the 
RCB and SCB to point to each other § and to establish the PS and HS connection. 
It then informs PS.CONV that a session has been successfully allocated via a 
SESSION_ALLOCATED record. 


When the input is a negative BID_RSP, this procedure changes the RCB so that 
it no longer points to the SCB that sent the BID_RSP, and retries the 
GET_SESSION request, which was stored in the RCB when the BID _RQ was issued, 
on another half-session. 


A negative bid response with sense data of X'088B0000' is handled specially. 
This bid response is sent by an LU to indicate that the session limit has been 


reset to 0 for a single-session connection and draining of the partner is not 


allowed. Sending of -BID_RSP(088B) is permitted only in the single-session 
case. . 


A -BID_RSP(088B) record may arrive from either a bidder or first-speaker ses- 
sion. If from a bidder session, it is in response to a previous bid. If from 
a first-speaker session, no previous bid was sent. A -BID_RSP(088B) record is 
the only bid response that can arrive from a first-speaker session. 


A positive or negative BID_RSP record 
SESSION_ALLOCATED to PS, or GET_SESSION to GET_SESSION_PROC (page 3-45) 


When a BID_RQ record is sent to HS, the RCB is set to point to the SCB for 
which the bid is being sent; the SCB, however, does not point to the RCB until 
a positive BID_RSP record is received. 


A -BID_RSP(088B) record indicates that the partner LU has reset the session 
limit to 0 and is not permitting draining of the local LU's requests. The 
session 1s deactivated with UNBIND(Cleanup). 


PS.CONV stores in the RCB information that helps HS to set the fields in the 
request/response header (RH). Part of the information states whether the data 
being sent to HS is the beginning of a conversation (in which case HS will set 
BBI) or is part of an existing conversation (in which case the BBI is set to 
“BB). When RM chooses a_ bidder half-session to allocate to PS.CONV, the 
BID_WITH_ATTACH or BID_WITHOUT_ATTACH record that RM sends to HS also triggers 
HS to set BBI to BB. Since PS.CONV is unaware of whether RM allocated a bid- 
der or first-speaker half-session (and thus does not Know whether the Begin 
Bracket, which is sent only once during a conversation, has already been 
sent), RM changes the information in the RCB to indicate to HS that the next 
record it receives from PS.CONV is not the start of a conversation. 


Referenced procedures, FSMs, and data structures: 


SEND_DEACTIVATE_SESSION page 3-55 
SET_RCB_AND_SCB_FIELDS page 3-61 
CONNECT_RCB_AND_SCB page 3-39 
GET_ SESSION_ PROC page 3-45 
PS page 5.0-5 
FSM_RCB_STATUS_FSP page 3-73 
FSM_RCB_STATUS_BIDDER page 3-72 
BID_RSP page A-14 
GET_SESSION page A-26 
RCB page A-7 
SESSION_ALLOCATED page A-33 
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If BID_RSP.RTI = NEG and BID_RSP.SENSE_ CODE = X'088B0000' then (see Note 2) 
Reset session limits for this mode to 0 and inform LU control operator. 
Call SEND_DEACTIVATE_SESSION(ACTIVE, BID _RSP.HS_ID, CLEANUP, X‘00000000' ) 

(page 3-55). 
Else 
Find the RCB associated with the conversation where 
state of #FSM_RCB_STATUS = PENDING_SCB (page 3-72) and 
RCB.HS_ID = BID_RSP.HS_ID. 
If BID_RSP.RTI = POS then 
Call SET_RCB_AND_SCB_FIELDS(RCB.RCB_ID, BID_RSP.HS_ID) (page 3-61). 


BID_RSP_PROC 


Call CONNECT_RCB_AND_SCB(RCB.RCB_ID, BID_RSP.HS_ID, REPLY) (page 3-39). 


Set RCB.PS_TO_HS_RECORD.ALLOCATE to NO (see Note 3). 
Create a SESSION _ALLOCATED record with RETURN_CODE set to OK. 
Send the SESSION_ALLOCATED to PS (Chapter 5.1). 
Else (-RSP(Bid)--retry request on another session) 
Set RCB.HS_ID to a null value. 
Call #FSM_RCB_STATUS(R, NEG_BID_RSP, UNDEFINED) (page 3-72). 
(State of #FSM_RCB_STATUS = FREE). 
If BID_RSP.SENSE_CODE = X‘'08140000' then 
Remember that the partner LU ones an RTR on this session. 
(Bidder cannot bid again for this session until RTR received). 
Create a GET_SESSION record initialized with the information from the 
GET_SESSION record, saved in the RCB when the BID record was sent. 
Call GET_SESSION_PROC(GET_SESSION) (page 3-45). 


original 
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BIDDER_PROC 


FUNCTION: 


NOTE : 


Referenced procedures, F5Ms, and data structures: 
HS 


This procedure handles the allocation processing for a bidder half-session. 


The HS_ID of the bidder half-session is placed in the RCB of the conversation 
for which the session was requested. The state of #FSM_RCB_STATUS is set to 
indicate that the conversation is pending confirmation that it can use the 
SCB. This procedure then creates a BID_WITHOUT_ATTACH or a BID_WITH_ATTACH 
record, depending on an indicator in the GET_SESSION record, and sends it to 
HS. If PS.CONV instructed RM to bid with an Attach, the Attach and any accom-~ 
panying data has already been stored in the RCB by PS.CONV before it issued 
the GET_SESSION request. 


GET_SESSION and HS_ID, the ID of the bidder half-session that was chosen by 
GET_SESSION_PROC (page 3-45) 


BID_WITHOUT_ATTACH or BID_WITH_ATTACH to HS. No SESSION_ALLOCATED record is 
sent to PS.CONV until confirmation that the bidder may use the session is 
received from the first-speaker (Ci.a., until a positive BID RSP is received). 


A copy of the GET_SESSION record is created so that, if the bid for the ses-~ 
sion fails, the request can be retried on a different session. 


page 6.0-3 
FSM_RCB_STATUS_FSP page 3-73 
FSM_RCB_STATUS_BIDDER | page 3-72 
GET _ SESSION page A-26 
HS_ID page 3-74 
BID_WITH_ATTACH page A-28 
BID_WITHOUT_ATTACH | | page A-29 
RCB page A-7 
Find the RCB associated with the conversation identified by GET_SESSION.RCB_ 10. 


Set RCB.HS_ID to HS_ID. 
Initialize SFSM_ RCB_ STATUS to FSM_RCB_ STATUS. BIDDER (page 3-72). 
Call #FSM_RCB _STATUS(S, GET_SESSION, UNDEFINED ) (page 3-72). 
Save the contents of the GET_SESSION record in the RCB (see Note). 
If GET_SESSION.BID_INDICATOR = ATTACH then 
If the security level of RCB.SECURITY_SELECT has been downgraded toa NONE and 
the Attach was previously built then 
Rebuild the Attach omitting the obsolete security information. 
Build a BID _WITH_ATTACH record where the BID_WITH_ATTACH.SEND_PARM fields 
are initialized with the corresponding RCB.PS_TO_HS_RECORD fields. 
Send the BID _WITH_ATTACH record to HS (Chapter 6.0). 
Else (GET_SESSION.BID_INDICATOR # ATTACH) 
Build and send a BID_WITHOUT ATTACH record to HS (Chapter 6.0). 
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BIS_RACE_LOSER 


FUNCTION: This procedure performs the processing necessary when a BIS race occurs and 
this side of the session is the race loser. 


This procedure first decrements the PENDING_TERMINATION_COUNT and issues a 
BIS_REPLY. It then attempts to find another session from the free-session 
pool on which to send a BIS_RQ. 

HS_ID, the ID of the session over which the BIS race occurred 


BIS_REPLY and, if there is a free session, BIS_RQ to HS 


When the SESSION_DEACTIVATION_POLARITY is EITHER, free first-speaker sessions 
are deactivated in preference to free bidder sessions. 


Referenced procedures, FSMs, and data structures: 


SEND_BIS_ RQ page 3-54 
SESSION_DEACTIVATISN_POLARITY page 3-60 

HS page 6.0-3 
HS_ID page 3-74 
LU_NAME page 3-74 
MODE_NAME page 3-74 
BIS REPLY page A-29 
MODE page A-3 


Let LU_NAME and MODE_NAME be the LU and mode names of the session identified 
by HS_ID. 
Get addressability to the MODE control block associated with (LU_NAME, MODE_NAME). 
Decrement MODE.PENDING_TERMINATION_CONWINNERS or MODE.PENDING_TERMINATION_CONLOSERS by 1, 
as appropriate to the session polarity. 
Create a BIS_REPLY record and send it to HS (Chapter 6.0). 
Call SESSION_DEACTIVATION_POLARITY(LU_NAME, MODE_NAME) (page 3-60). 
to determine the polarity of an additional session to deactivate (if any). 
If there is a free session of the appropriate type then (see Note) 
Call SEND_BIS_RQ(HS_ID) (page 3-54). 
Remove the session from the free-session pool. 


BIS_REPLY_PROC 


FUNCTION: This procedure processes BIS replies. 


The procedure invokes #FSM_BIS associated with the half-session over which the 
BIS_REPLY was received. 


INPUT: BIS_REPLY 


OUTPUT: #FSM_BIS is invoked 


Referenced procedures, FSMs, and data structures: 


FSM_BIS_BIDDER page 3-70 
FSM_BIS_FSP page 3-71 
BIS_REPLY page A-14 


Call #FSM_BIS(R, BIS_REPLY, HS_ID) (page 3-70) 
for the half-session over which the BIS_REPLY was received. 
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BIS_RQ_PROC 


FUNCTION: This procedure processes BIS requests. 


This procedure invokes #FSM_BIS associated with the half-session over which 
the BIS_RQ was received. | 


INPUT : BIS_RQ 


OUTPUT: #FSM_BIS is invoked 


Referenced procedures, FSMs, and data structures: 


FSM_BIS_BIDDER page 3-70. 
FSM_BIS_FSP page 3-71 
BIS_RQ | page A-14.. 


Call #FSM_BIS(R, BIS_RQ, HS_ID) (page 3-70) 
associated with the half-session over which the BIS_RQ was received. 
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CHANGE_SESSIONS_PROC 


FUNCTION: This procedure performs the processing that is required when two LU service 
transaction programs exchange CHANGE _NUMBER_OF_SESSIONS requests anda new 
session limit is agreed upon. PS.COPR (Chapter 5.4) sends CHANGE_SESSIONS to 
RM after CHANGE_NUMBER_OF_SESSIONS requests have been successfully exchanged. 


A new TERMINATION_COUNT is computed based on the information in the 
CHANGE_SESSIONS record. If the new TERMINATION_COUNT is greater than 0, ses- 
sions have to be deactivated. Pending active sessions are deactivated first 
followed by free sessions. If the TERMINATION_COUNT is still greater than 0; 
sessions will be deactivated later when they become free. 


After pending and free sessions have been deactivated as required, additional 
sessions may be activated if the current session count (by polarity, i.e.; 
CONWINNER or CONLOSER) is less than the minimum limits. This procedure may 
have to request both deactivation and activation of sessions if, for example, 
the total session limit remains constant, but the mix of first speakers and 
bidders changes. 


INPUT: CHANGE _SESSIONS 
OUTPUT: ACTIVATE_SESSION to LNS, BIS_RQ@ to HS», or none 
NOTE: An implementation may choose not to deactivate pending active sessions. If, 


however, the TERMINATION_COUNT is nonzero when the session becomes active, the 
session has to then be deactivated. 


Referenced procedures, FSMs, and data structures: 


CHANGE _SESSIONS page A-26 
MODE “page A-3 

SESSION_ALLOCATED page A~-33 
DEACTIVATE_PENDING_SESSIONS page 3-41 
DEACTIVATE_FREE_SESSIONS page 3-41 
ACTIVATE_NEEDED_SESSIONS page 3-22 


If CHANGE_SESSIONS.RESPONSIBLE is YES then 
Get addressability to the MODE control block associated with CHANGE SESSIONS. LU_NAME 
and CHANGE_SESSIONS.MODE_NAME. 
Set CONWINNER_COUNT to MODE.ACTIVE_CONWINNERS COUNT + MODE .PENDING_CONWINNERS_COUNT. 
Set CONLOSER_COUNT to MODE.ACTIVE_CONLOSERS_COUNT + MODE.PENDING_CONLOSERS_COUNT. 
Set OLD_SESSION_LIMIT to MODE.SESSION_LIMIT - CHANGE_SESSIONS.DELTA. 
Set PLATEAU to 
min(MODE.ACTIVE_SESSION_COUNT + MODE .°ENDING_SESSION_COUNT, OLD_SESSION_LIMIT). 
Set CONWINNER_INCREMENT to m3x.0, MODE.MIN_CONWINNERS_LIMIT - CONWINNER_COUNT). 
Set SESSION _DECREMENT to max(0, PLATEAU - MODE.SESSION_LIMIT). 
Set CONLGSER_INCREMENT to max(€0, MODE.MIN_CONLOSERS LIMIT - CONLOSER_COUNT). 
vet NEED _TO_ACTIVATE to CONWINNER_INCREMENT + CONLOSER_INCREMENT. 
Set ROOM_FOR_ACTIVATION to max(0, MOCE.SESSION_LIMIT - PLATEAU). 
Set DECREMENT_FOR_POLARITY to max(0, NEED_TO_ACTIVATE ~- ROOM_FOR_ACTIVATION). 
Set MODE.TERMINATION_COUNT to MODE. TERMINATION_COUNT + SESSION_DECREMENT + 
DECREMENT_FOR_POLARITY. 
If MODE.TERMINATION_COUNT > 0 then 
Call DEACTIVATE_PENDING_SESSIONS( CHANGE_SESSIONS.LU_NAME, CHANGE_SESSIONS.MODE_NAME ) 
(page 3-41, see Note). 
If MODE.TERMINATION_COUNT > 0 then 
Call DEACTIVATE_FREE_SESSIONS( CHANGE_SESSIONS.LU_NAME, CHANGE_SESSIONS.MODE_NAME ) 
. (page 3-41). 
If MODE.SESSION_LIMIT = 0, and 
MODE.DRAIN_SELF = NO or MODE.ACTIVE_SESSION_COUNT = 0 then 
Do for each waiting request for a session with (CHANGE_SESSIONS.LU_NAME, 
CHANGE_SESSIONS.MODE_NAME ): 
Create a SESSION_ALLOCATED record with RETURN_CODE set to UNSUCCESSFUL_NO_RETRY 
and send it to the PS that made the request. 
Discard the waiting request. 
Call ACTIVATE_NEEDED_SESSIONS( CHANGE_SESSIONS.LU_NAME, CHANGE_SESSIONS.MODE_NAME) to 
activate new sessions if possible and if needed (page 3-22). 


Chapter 3. LU Resources Manager 3-37 


CHECK_FOR_BIS_REPLY 


_ CHECK_FOR_BIS_ REPLY 


This procedure checks to see if a BIS_REPLY should be sent at the present time 


to respond to a received BIS_RQ. 
HS_ID, the ID of the half-session that sent the BIS_RQ 
BIS_REPLY to HS, or no output 


Referenced procedures, FSMs, and data structures: 


SEND_BIS_REPLY page 3-53 
HS_ID page 3-74 
MODE page A-3 


Get addressability to the MODE control block associated with the LU and mode 
name of the session identified by HS_ID. 
If MODE.DRAIN_SELF = NO or 
(MODE .DRAIN_SELF = YES and there are no waiting requests for the LU and mode name) then 
If the session identified by HS_ID is free then 
Call SEND_BIS_REPLY(HS_ID) (page 3-53). 
Remove the session from the free-session pool. 


COMPLETE_HS_ATTACH 


This procedure performs processing that is required only if the Attach came to 
RM from HS (as opposed to UPM_IPL). 


The SCB corresponding to the session over which the Attach was received is 
changed to point to the appropriate RCB, and the status of the SCB is set to 
IN_USE. 


HS_ID, the ID of the session from which the Attach was received, RCB_ID, the 
ID of the conversation resource that is to use the session, and TCB_ID, the ID 
of the PS that was created as a result of the Attach 


None 


Referenced procedures, FSMs, and data structures: 


CONNECT_RCB_AND_SCB page 3-39 
FSM_SCB_STATUS_BIDDER page 3-68 
FSM_SCB_STATUS_FSP page 3-69 
HS_ID page 3-74 
RCB_ID | | page 3-74 
TCB_ID | page 3-74 
SCB page A-9 


Call 8FSM_SCB_STATUS(R, ATTACH, UNDEFINED) (page 3-67) 
associated with the half-session identified by HS_IO. 
(State of &FSM_SCB_STATUS = IN_USE). 

Set SCB.RCB_ID to RCB_LID. | 

Call CONNECT_RCB_AND_SCB(RCB_ID, HS_ID, REPLY) (page 3-39). 
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CONNECT_RCB_AND_SCB 


FUNCTION: 


INPUT: 


OUTPUT : 


This procedure connects a PS and HS process, and informs HS when the con- 
nection is complete. 


RCB_ID and HS_ID, the IDs of the RCB representing the conversation resource 
and the SCB representing the half-session 


HS_PS_CONNECTED record is sent to HS. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
PS page 5.0-5 
RCB_ID page 3-74 
HS_ID page 3-74 
HS_PS_CONNECTED page A-29 


Connect the PS process that is using the conversation identified by RCB_ID to 
the half-session identified by HS_ID. 
Create an HS_PS_CONNECTED record and send it to HS (Chapter 6.0). 


CREATE_RCB 


This procedure handles the creation of new RCBs. It places the RCB_ID of the 
newly created entry into the passed RCB_ALLOCATED record. 


ALLOCATE_RCB and RCB_ALLOCATED. The RCB_ALLOCATED was created by ALLO- 
CATE_RCB_PROC (page 3-24). 


RCB_ALLOCATED with the RCB_ID field set to the ID of the new RCB 


8FSM_RCB_STATUS is a generic FSM that can be either FSM_RCB_STATUS_FSP or 
FSM_RCB_STATUS_BIDDER, depending on whether the conversation resource is using 
a first-speaker or a bidder half-session. When a new RCB is created, it is 
not usually known which type of half-session will be available (except for 
ALLOCATE_RCB( IMMEDIATE), which must use a first-speaker half-session in order 
to be successful). Therefore, when the RCB is created, the FSM is initialized 
to FSM_RCB_STATUS_FSP, and is changed later if the conversation will be run- 
ning on a bidder half-session. 


Referenced procedures, FSits, and data structures: 


ALLOCATE_RCB page A-25 
RCB_ALLOCATED page A-32 
RCB page A-7 


Create RCB, set RCB.RCB_ID to a wique value and RCB.HS_ID to a null value. 

Move TCB_ID, LU_NAME, and MODE_NAME from the ALLOCATE_RCB record to the RCB. 

Place the RCB_ID in the RCB_ALLOCATED record. 

Set #FSM_RCB_STATUS = FSM_RCB_STATUS_FSP (page 3-73; see Note). 

Call #FSM_RCB_STATUS(S, ALLOCATE_RCB, UNDEFINED) (state of the FSM is set to FREE, 


page 3-72). 


Set RCB.CONVERSATION CORRELATOR to a unique value. 

Set RCB.SYNC_LEVEL to ALLOCATE_RCB.SYNC_LEVEL. 

Set RCB.SECURITY_SELECT to ALLOCATE_RCB.SECURITY_SELECT. 

Set RCB.PS_TO_HS_RECORD type to SEND_DATA_RECORD and RCB.PS_TO_HS_RECORD data to a null value. 
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CREATE_SCB 


FUNCTION: This procedure creates a new SCB based on the LU_NAME, MODE_NAME and SES- 
SION_INFORMATION arguments. | 


INPUT: LU_NAME and MODE_NAME of the partner LU; and SESSION_INFORMATION, which 
describes the session attributes 


OUTPUT : A new SCB is created. 


Referenced procedures, FSMs, and data structures: 


FSM_SCB_STATUS_BIDDER | page 3-68 
FSM_SCB_STATUS_FSP page 3-69 
FSM_BIS_BIDDER page 3-70 
FSM_BIS_FSP page 3~71 
LU_NAME page 3-74 
MODE_NAME page 3-74 
SESSION_INFORMATION page A-36 
SCB page A-9 


Create an SCB, set SCB.HS_ID to SESSION_INFORMATION.HS_ID, SCB.LU_NAME to 
LU_NAME, SCB.MODE_NAME to MODE_NAME, SCB.RCB_ID to a null value, “and 
SCB.RANDOM_DATA to SESSION_ INFORMATION. RANDOM_DATA. 

Select based on SESSION_INFORMATION.BRACKET_TYPE: 

If the half-session is a first-speaker then 

Assign finite-state machines to be used by setting 
#FSM_BIS to FSM_BIS_FSP (page 3-71) 
and #FSM_SCB_STATUS to FSM_SCB_STATUS_FSP (page 3-69). 

Else (bidder session) 

Assign finite-state machines to be used by setting 
#FSM_BIS to FSM_BIS_ BIDDER (page 3-70) 
and #FSM_SCB_STATUS to FSM_SCB_STATUS_BIDDER (page 3-68). 


CTERM_DEACTIVATE_SESSION_PROC 


FUNCTION: This procedure handles —_ the processing that occurs when 
CTERM_DEACTIVATE_SESSION record is received from LNS. 


The session identified by CTERM_DEACTIVATE_SESSION.HS_ID is deactivated with a 
BIS_RQ-BIS_REPLY exchange followed by UNBIND(NORMAL). The processing of this 


record is identical to that of an operator verb DEACTIVATE_SESSION( NORMAL). 


INPUT : CTERM_DEACTIVATE_SESSION 


OUTPUT: Session deactivation processing is initiated. 


Referenced procedures, FSMs, and data structures: 


RM_DEACTIVATE_SESSION_PROC page 3-49 
CTERM_DEACTIVATE_SESSION page A-20 
RM_DEACTIVATE_SESSION page A-27 


Create an RM_DEACTIVATE_SESSION record with TCB_ID set to a null value, SESSION_ID set to 
CTERM_DEACTIVATE_SESSION.HS_ID, and TYPE set to NORMAL. 
Call RM_DEACTIVATE_SESSION_PROC(RM_DEACTIVATE_SESSION) (page 3-49). 
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DEACTIVATE_FREE_SESSIONS 
DEACTIVATE_FREE_SESSIONS 


This procedure requests deactivation of free sessions between this LU and the 
partner LU identified by (LU_NAME, MODE_NAME). Deactivations are requested 
until either all free sessions have had deactivation requested, or this LU is 
not responsible for any more deactivations. 


The LU_LNAME of the partner LU and the MODE_NAME of the sessions to be deacti- 
vated 


Zero or more DEACTIVATE_SESSION records to LNS 


First-speaker sessions are deactivated before bidder sessions. 


Referenced procedures, FSMs, and data structures: 


SESSION_DEACTIVATION_POLARITY page 3-60 
SEND_BIS page 3-53 
LU_NAME 

MODE_NAME 

HS_ID 


Do while there exists a free session of a polarity matching that returned by 
SESSION_DEACTIVATION_POLARITY(LU_NAME, MODE_NAME) (page 3~-60): 
(If SESSION_DEACTIVATION_POLARITY returns EITHER, a first-speaker session is 
deactivated in preference to a bidder session. ) 
Let HS_ID be the identifier of the session to be deactivated. 
Call SEND_BIS(HS_ID) (page 3-53). 
Remove the session from the free-session pool. 


DEACTIVATE_PENDING_ SESSIONS 


FUNCTION: This procedure requests deactivation of pending-active sessions between this 
LU and the partner LU identified by (LU_LNAME, MODE_NAME). Deactivations are 
requested until either all pending-active sessions hava had deactivation 
requested, or this LU is not responsible for any more deactivations. 

INPUT: LU_NAME of the partner LU and the MODE_NAME of the sessions to be deactivated 


OUTPUT: Zero or more DEACTIVATE_SESSION records to LNS 


Referenced procedures, FSMs, and data structures: 


SESSION_DEACTIVATION_POLARITY page 3-60 
SEND_DEACTIVATE_SESSION page 3-55 
LU_NAME page 3-74 
MODE_NAME page 3-74 
MODE page A-3 


Get addressability to the MODE control block associated with (LU_NAME, MODE NAME). 
Do while there are pending-active first-speaker sessions for (LU_ NAME, MODE “NAME ) > and 
SESSION_DEACTIVATION_POLARITY(LU_NAME, MODE_NAME) (page 3-60) 
indicates FIRST_ SPEAKER or EITHER: | 
Call SEND_ DEACTIVATE SESSION( PENDING, PENDING_ACTIVATION.CORRELATOR, NORMAL, ¥%'00000000' ) 
(page 3-55). 
Decrement MODE.TERMINATION_COUNT by 1. 
Do while there are pending-active bidder sessions for (LU_NAME, MODE_NAME), and 
SESSION_DEACTIVATION_POLARITY(LU_NAME, MODE_NAME) (page 3-60) 
indicates BIDDER or EITHER. 
Call SEND_DEACTIVATE_SESSION( PENDING, PENDING ACTIVATION.CORRELATOR, NORMAL, X'00000000' ) 
(page 3-55). 
Decrement MODE. TERMINATION_ COUNT by 1. 
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DEQUEUVE_WAITING_ REQUEST 


This procedure checks to see if there are any GET_SESSION requests waiting to 


be serviced. If so, this procedure dequeves§ the first request and invokes 
GET_SESSION_PROC (page 3-45) to process the request. 


INPUT : HS_ID, the ID of a half-session. 


GET_SESSION_PROC is invoked to process the waiting request 


Referenced procedures, FSMs, and data structures: 
GET_SESSION_PROC | ' 


page 3-45 
GET_SESSION page A-26 
HS_ID — | page 3-74 
LU_NAME : | paye 3-74 
MODE_NAME page 3-74 


Let LU_NAME and MODE_NAME be the LU name and mode name of the session identified by HS_ID. 
If there is a waiting request for a session on (LU_NAME, MODE_NAME) then 

Initialize a GET_SESSION record with the information from the waiting request. 

Call GET_SESSION_PROC(GET_SESSION) (page 3-45) to service the request. 

Remove the waiting request from the queue. 
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FIRST_SPEAKER_PROC 


This procedure handles the allocation processing for a first-speaker 
hal f-session. 


This procedure causes the SCB associated with the first-speaker half-session 
and the RCB of the conversation for which the session was requested to be con- 
nected to each other. If PS.CONV indicated that RM is to be responsible for 
sending the Attach, it creates a BID_WITH_ATTACH record from information that 
PS.CONV stored in the RCB and sends it to HS. It then creates a SES- 
SION_ALLOCATED record, which it sends to PS.CONV to inform PS.CONV that a ses- 


sion has been successfully allocated. 


GET_SESSION and HS_ID, the ID of the first-speaker half-session that was cho- 
sen by GET_SESSION_PROC (page 3-45) 


SESSION_ALLOCATED to PS3 and, if PS.CONV has indicated that RM is to send the 
Attach for the conversation, BID_WITH_ATTACH to HS 


Since GET_SESSION_PROC was able to obtain a first-speaker half-session, the 
Attach that RM sends to HS is not really a bid for the use of the session. 
After RM sends the Attach it does not have to wait for a response from HS but 
can report immediately to PS.CONV. 


Referenced procedures, FSMs, and data structures: 


SET_RCB_AND_SCB_FIELDS page 3-61 
CONNECT_RCB_AND_SCB page 3-39 
HS page 6.0-3 
PS page 5.0-5 
GET_SESSION page A-26 
BID_WITH_ATTACH page A-28 
RCB page A-7 
SESSION_ALLOCATED page A-33 
HS_ID page 3-74 


Call SET_RCB_AND_SCB_FIELDS(GET_SESSION.RCB_ID, HS_ID) (page 3-61). 
¥f GET_SESSION.BID_INDICATOR is ATTACH then 
If the security level of RCB.SECURITY_SELECT has been downgraded to NONE and 
the Attach was previously built then 
Rebuild the Attach omitting the obsolete security information. 
Create BID_WITH_ATTACH (see Note) with the SEND_PARM subfields initialized 
to the corresponding RCB.PS_TO_HS_RECORD subfields. 
Send the BID_WITH_ATTACH to HS (Chapter 6.0). 
Call CONNECT_RCB_AND_SCB(GET_SESSION.RCB_ID, HS_ID, NORMAL) (page 3-39). 
Create a SESSION_ALLOCATED record, set RETURN_CODE to OK, and send record to PS 
(Chapter 5.1). 
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| FREE_SESSION_PROC 


This procedure handles the processing that occurs when a session becomes free. 


This procedure first checks to see if a bid is outstanding on this session. 
If so, the session is not returned to the free-session pool. If not, the pro- 
cedure checks to see if an RTR_R@ or a BIS request or reply is to be sent. If 
either RTR_RQ or BIS is sent, the session is not returned to the free-session 

pool. If neither BIS nor RTR is sent, the free-session is returned to the 
a pool, and a waiting session allocation request (if any) is serv~ 
ic 


FREE_SESSION 


BIS_RQ, BIS_REPLY, or RTR_RQ to HS$ or GET_ SESSION to GET_ SESSION_ PROC (page 
3~45)3 or no output 


¥f an RTR is owed on this session (either the partner LU owes RTR to the local 
LU or the local LU owes RTR to the partner), the bidder has to wait for an RTR 
from the first-speaker before it can again bid for the session. Therefore, 
the deallocated bidder session is not returned to the free-session pool and a 
waiting request is not serviced. 


Referenced procedures, FSMs, and data structures: 


DEQUEUE_WAITING_ REQUEST page 3-42 
SHOULD_SEND_BIS page 3-62 
_SEND_BIS | page 3-53 
RM_PROTOCOL_ERROR page 3-49 
HS page 6.0-3 
FSM_SCB_STATUS_BIDDER page 3-68 
FSM_SCB_STATUS_FSP page 3-69 
FSM_BIS_ BIDDER page 3-70 
FSM_BIS_FSP 3 | page 3-71 
FREE SESSION | ? page A-15 
SCB page A-9 
RCB | page A-7 
RTR_RQ page A-30 


Find the SCB associated with the session identified by FREE_SESSION.HS_ID. 
Set SCB.RCB_ID to a null value. 
If the state of #FSM_SCB_STATUS is PENDING_FMH12 then (page 3-67). 
Call RM_PROTOCOL_ERROR (page 3-49). 
Call SFSM_SCB_STATUS(R» FREE_SESSION, UNDEFINED) (page 3-67). 
If there is an RCB for which the state of 8FSM_RCB_STATUS is PENDING_SCB, 
and RCB.HS_ID = SCB.HS_ID then 
Take no action and return to the calling routine (a BID is pending). 
Else if RTR is owed on this session then 
If this is a first-speaker session (i.e., this LU owes RTR) then 
If there are no waiting requests for sessions, and 
RTR is to be sent now Cimplementation-defined choice) then 
Send RTR_RQ to HS (Chapter 6.0). 
Reset RTR owed indication for this session. 
Else (bidder session; i.e., other LU owes RTR) then. 
Take no action and return to the calling routine (see Note). 
Else 
Call SHOULD_SEND_BIS(SCB.HS_ID) (page 3-62) to determine 
whether BIS should be sent now. 
If BIS should be sent now then 
Call SEND_BIS(SCB.HS_ID) (page 3-53). 
If the state of &FSM_BIS (page 3-70) is BIS_SENT or CLOSED then 
Take no action and return to the calling routine (BIS has been sent). 
Else (the session is available for reuse) 
Return the session to the free-session pool. 
Call DEQUEUVE_WAITING REQUEST(SCB.HS_ID) (page 3-42). 
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GET_SESSION_PROC 


FUNCTION: This procedure handles the allocation of half-sessions to be used by conversa- 
tion resources. 


The procedure checks for an available half-session and calls the appropriate 
procedure, depending upon whether the half-session found was a first-speaker 
or a bidder half-session. If there are no half-sessions available and the 
current session limit has not been reached, SEND _ACTIVATE_SESSION is called, 
which requests that LNS activate a new session. 


INPUT : GET_SESSION 


OUTPUT: See called procedures for output. 


NOTES: 1. When PS.CONV requests a session from the resources manager, RM does the fol- 
lowing: attempts to service the request with a first-speaker half-session; if 
none is available, RM attempts to service the request with a bidder 
half-session; failing that, RM requests LU network services to activate a new 
session if the current session limit has not been reached. If a first-speaker 


half-session is available, that session is used to service the session 
request. If no first-speaker half-sessions are available, an implementation 
can choose to service the request with a free bidder half-session, activate a 
new first-speaker half-session, or both of the above. An implementation 
could, for example, choose to implement the following order: choose a free 
first-speaker half-session; request a new first-speaker half-session be acti- 
vated; and, finally, choose a_ free bidder half-session. (Another possibility 
is that an implementation could service the session request with a bidder 
half-session, if no first-speaker half-sessions are available, but at the same 
time ask that a new first-speaker half-session be activated.) However, if 
there are no free first-speaker half-sessions and the session limit for the 
desired (LU name, mode name) pair has been reached, the session request is 
serviced with a bidder half-session, if available. If a bidder half-session 
is available, an implementation does not wait for a first-speaker half-session 
to become free before servicing the session request. 


A mode is closed if there are no sessions active for the mode name and a ses- 
sion cannot be activated without operator intervention (e.g., the operator 
must increase the session limit above 0). In this case, the GET_SESSION 
request is rejected with a return code of UNSUCCESSFUL_NO_RETRY. 


Referenced procedures, FSMs, and data structures: 


FIRST_SPEAKER_PROC page 3-43 
BIDDER_PROC page 3-34 
SESSION_ACTIVATION_POLARITY page 3-57 
SEND_ACTIVATE_SESSION paqea 3-52 
PS page 5.0-5 
GET_SESSION page A-26 
RCB page A-7 
SESSION_4LLOCATED page A-33 
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GET_SESSION_PROC 


3-46 


If the mode is closed then (see Note 2) 
Send SESSION_ALLOCATED record with a return code of UNSUCCESSFUL_NO_RETRY to 
PS (Chapter 5.1). 
Else 
If the (GET_SESSION.LU_NAME, GET_SESSION.MODE_NAME) sessions do not support the 
requested sync level then 
Send SESSION_ALLOCATED record with a return code of SYNC_LEVEL_NOT_SUPPORTED. 
Else 
If the (GET_SESSION.LU_NAME, GET_ SESSION. MODE_NAME) sessions do not support the 
requested security level then 
Luowngrace the SECURITY_SELECT field of the RCB by setting it to NONE. 
If a free session exists then 
If first-speaker half-session then 
Call FIRST_SPEAKER_PROC(GET_SESSION, HS_ID) (page 3-43). 
Else (bidder half-session) 
Call BIDDER_PROC(GET_SESSION, HS_ID) (page 3-34). 
Remove the session from the free-session pool. 
Else (no free session exists) 
If there are more waiting requests for sessions than there are 
pending session requests then 
Call SESSION_ACTIVATION_POLARITY(GET_SESSION.LU_NAME, GET_SESSION.MODE_NAME ) 
(page 3-57) 
to determine the polarity of the next activated session (if any). 
Select based on session activation polarity: 
When NONE (no new sessions can be activated) 
Do nothing. 
When FIRST_SPEAKER 
Call SEND _ACTIVATE_SESSION(GET_SESSION. LU_NAME, GET_ SESSION. MODE_NAME » 
FIRST_SPEAKER) (page 3-52). 
When BIDDER 
Call SEND_ACTIVATE_SESSION(GET_SESSION.LU_NAME, GET_SESSION.MODE_NAME » 
BIDDER) (page 3- 52). 
Queue the waiting request for a session. 
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PS_CREATION_PROC 


FUNCTION: This procedure creates a new instance of the PS process. 


This procedure is called upon receipt of an Attach from HS or UPM_IPL. Along 
with creating the PS process, it also creates a new TCB and RCB. It returns 
to the calling procedure the IDs of the newly created TCB and RCB, which the 
calling procedure will send to PS along with the Attach that it received. 


ATTACH_HEADER, an indicator stating whether the Attach sender was HS or 
UPM_IPL, and variables in which the TCB_ID and RCB_ID will be returned 


The IDs of the newly created TCB and RCB 


If the Attach sender is UPM_IPL, the status of the FSM associated with the RCB 
is set to INITIAL. This indicates that the ATTACH that caused this RCB to be 
created came from UPM_IPL and that there is no half-session associated with 
this conversation. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
FSM_RCB_STATUS_FSP page 3-73 
FSM_RCB_STATUS_BIDDER page 3-72 
ATTACH_HEADER page A-13 
TCB page A-10 
RCB page A-7 


| Create a TCB with a unique TCB_ID, initializing TRANSACTION_PROGRAM_NAME, 
| INITIATING SECURITY.USERID, and INITIATING_SECURITY.PROFILE to null 
| and CONTROLLING_COMPONENT to TP. 

Create an RCB with a unique RCB_ID, initializing RCB.TCB_ID to TCB_ID; 
RCB.PS_TO_HS_RECORD.VARIANT_NAME to SEND_DATA_RECORD, RCB.PS_TO_HS_RECORD.DATA 
to null, and RCB.HS_TO_PS_BUFFER_LIST to empty. 

| If there is a conversation correlator present in the Attach 
| Set the RCB.CONVERSATION_CORRELATOR to the conversation correlator in the Attach. 
Select based on Attach sender: 
When HS 
If the session is a first speaker then 
Set #FSM_RCB_STATUS to FSM_RCB_STATUS_FSP (page 3-73). 
Else 
Set #FSM_RCB_ STATUS to FSM_RCB_STATUS_BIDDER (page 3-72). 
Call #FSM_RCB_STATUS(R, ATTACH, HS) (page 3-72) 
(State of #FSM_RCB_STATUS = IN_USE). 
Set RCB.HS_ID to ATTACH_HEADER.HS_ID. 
When UPM_IPL 
Set #FSM_RCB_STATUS to FSM_RCB_STATUS_FSP (page 3-73). 
Call #FSM_RCB_STATUS(R, ATTACH, UPM) (page 3-72) 
(State of #FSM_RCB_STATUS = INITIAL). 
RCB.HS_ID = ATTACH_HEADER.HS_ID; 
Create a new PS process (page 5.0-5). 


Chapter 3. LU Resources Manager 3-47 


RM_ACTIVATE_SESSION_PROC 
RM_ACTIVATE_SESSION_PROC 


FUNCTION: This procedure performs the processing of the RM_ACTIVATE_SESSION record. 

An RM_ACTIVATE_SESSION record is sent to RM by PS.COPR (Chapter 5.4) when the 
control operator issues an ACTIVATE_SESSION command. The command directs RM 
to activate anew session to the partner LU identified by LU_LNAME with the 
mode specified by MODE_NAME. 


RM replies to the RM_ACTIVATE_SESSION record with an RM_SESSION_ACTIVATED 
record. The RETURN_CODE field of RM_SESSION_ACTIVATED indicates the success 
or failure of the session activation. 


INPUT: RM_ACTIVATE_SESSION 


OUTPUT: ACTIVATE_SESSION to LNS; or RM_SESSION_ ROIS OTED with RETURN_CODE 
LU_MODE _SESSION_ LIMIT_EXCEEDED to PS 


Referenced procedures, FSMs, and data structures: 


SESSION_ACTIVATION_POLARITY | page 3-57 
SEND_ACTIVATE_SESSION page 3-52 
PS page 5.0-5 
RM_ACTIVATE_SESSION page A-27 
RM_SESSION_ACTIVATED page A-33 


Create an RM_SESSION_ACTIVATED record. 
Call SESSION_ ACTIVATION. POLARITY(RM_ACTIVATE_SESSION.LU_ NAME» 
RM_ACTIVATE_SESSION.MODE_NAME) (page 3-57) 
to determine the polarity of the next activated session (if any). 
Select based on the activation polarity: 
When NONE (session limit exceeded) 
Set RM_SESSION_ACTIVATED .RETURN_CODE to LU_MODE_SESSION_LIMIT_EXCEEDED. 
Send the RM_SESSION_ACTIVATED record to PS (Chapter 5.4). 
When FIRST_SPEAKER 
Call SEND_ACTIVATE_SESSION(RM_ACTIVATE_SESSION. LU_NAME >» 
RM_ACTIVATE_SESSION.MODE_NAME, FIRST_SPEAKER) (page 3-52). 
. Save the RM_SESSION_ACTIVATED record as a pending CNOS operator activation request. 
When BIDDER 
Call SEND_ACTIVATE_SESSION(RM_ACTIVATE_SESSION.LU_NAME, 
RM_ACTIVATE_SESSION.MODE_NAME, BIDDER) (page 3-52). 
Save the RM_SESSION_ACTIVATED record as a pending CNOS operator activation request. 
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RM_DEACTIVATE_SESSION_PROC 


This procedure performs the processing of the RM_DEACTIVATE_SESSION record. 


An RM_DEACTIVATE_SESSION record is sent to RM by PS.COPR (Chapter 5.4) when 
the control operator issues a DEACTIVATE_SESSION command. The command directs 
RM = to deactivate the session identified by SESSION_ID. An 
RM_DEACTIVATE_SESSION record is also generated internally in RM during the 
processing of a CTERM_DEACTIVATE_SESSION record from LU network services. 


RM_DEACTIVATE_SESSION 


DEACTIVATE_SESSION to UNS, BIS_RQ to HS, or no output 


Referenced procedures, FSMs, and data structures: 


SEND_DEACTIVATE_SESSION , page 3-55 
SEND_BIS_RQ page 3-54 
FSM_BIS_BIDDER page 3-70 
FSM_BIS_FSP page 3-71 
RM_DEACTIVATE_SESSION page A-27 


Select based on RM_DEACTIVATE_SESSION.TYPE: 
When CLEANUP 
Call SEND_DEACTIVATE_SESSION( ACTIVE, RM_DEACTIVATE_SESSION.SESSION_ID, 
CLEANUP, X‘'00000000°) (page 3-55). 
When NORMAL 
If session exists then 
If the session is in use then | 
If state of #FSM_BIS (page 3-70) # BIS_SENT then (BIS not already sent) 
Queue the deactivation request. 
Else (session not in use) 
Call SEND_BIS_RQ(HS_ID) (page 3-54). 
Remove the session from the free-session pool. 


RM_PROTOCOL ERROR 


This procedure processes receive error conditions. These errors occur when 
the other half-session violates the architecture. This procedure takes the 
following actions: 


® Ends the session by requesting LU network services to send UNBIND. (The 
other half-session has committed a serious violation of the architecture. ) 
The UNBIND is type X'FE', indicating invalid session protocol, and carries 
sense data indicating the nature of the receive check error. 


Notifies the appropriate operator associated with the NAU (the terminal or 
subsystem operator). Some implementations may not have an appropriate 
operator to report to. 


®  togs the error. 


HS_ID, the ID of the half-session and SENSE_CODE, the sense data to be placed 
in the UNBINOD 


See FUNCTION. 


Referenced procedures, FSMs, and data structures: 


SEND_DEACTIVATE_SESSION page 3-55 
HS _ID page 3-74 
SENSE_CODE page 3-75 


Call SEND _DEACTIVATE_SESSION( ACTIVE, HS_ID, ABNORMAL, SENSE_CODE) (page 3-55). 
Log the protocol error. 
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RTR_RQ_PROC 


FUNCTION: This procedure handles the receipt of RTR requests froma i first-speaker 
half-session. 


The session is returned to the free-session pool, and if there is a waiting 
request, the request is processed anda +RSP(RTR) is sent to the resources 
manager of the first-speaker half-session. If not, a -RSP(RTR, 0819) is sent 
to the resources manager to indicate that the resources manager of the bidder 
half-session has no*hing to send. 


INPUT: — ®&IR_RQ from HS 


OUTPUT: Positive RTR_RSP, or negative RTR_RSP(SENSE_CODE = X'08190000') to 


Referenced procedures, FSMs, and data structures: 


GET_SESSION_PROC page 3-45 
RM_PROTOCOL_ERROR page 3-49 
SHOULD_SEND_BIS | page 3-62 
SEND_BIS page 3-53 
HS page 6.0-3 
RTR_RQ page A-15 
GET_SESSION page A-26 
RTR_RSP 3 page A-30 


If the partner LU owes an RTR then 
If there are any waiting requests for sessions with the partner LU and mode name then 
Create an RTR_RSP record with RTI set to POS and SENSE_ CODE set to X'00000000'. 
Send the RTR_ RSP record to HS (Chapter 6.0). 
Create a GET_SESSION record from the information saved in the waiting request. 
Call GET_SESSION_PROC(GET_SESSION) (page 3-45) to process the request. 
Else (no waiting requests } 
Create an RTR_RSP record with RTI set to NEG and SENSE_CODE set to X'08190000'. 
Send the RTR_RSP record to HS (Chapter 6.0). 
Call SHOULD_SEND_BIS(RTR_RQ.HS_ID) (page 3-62) to determine whether 
BIS should be sent on this session. 
If BIS should be sent then 
Call SEND_BIS(RTR_RQ.HS_ID) (page 3-53). 
Else 
Return the session to the free-session pool. 
Remember that the partner LU no longer owes an RTR. 
Else (RTR not expected) 
Call RM_PROTOCOL_ERROR(RTR_RQ. HS_ ID, X'20030000') (page 3-49). 
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RTR_RSP_PROC 
RTR_RSP_PROC 


FUNCTION: This procedure handles the receipt of RTR responses from a_i bidder 
half-session. 


If the input is a positive RTR_RSP, no processing is performed. If the input 
is a negative RTR_RSP(SENSE_CODE = 0819), the session is returned to the 
free-session pool, and the session is used to service a waiting request (if 
any). 


INPUT: Positive or negative RTR_RSP from HS 


OUTPUT: None 


NOTE: If #FSM_BIS is not in the RESET state when RTR_RSP is received, this procedure 
does not return the session to the free-session pool, since the session is in 
the process of being shut down. This can occur, for example, when the first 
speaker has sent a BIS and the bidder responds negatively to a previous RTR 
before sending its own BIS. 


Referenced procedures, FSMs, and data structures: 


DEQUEVE_WAITING_ REQUEST page 3-42 
SHOULD_SEND_BIS page 3-62 
SEND_BIS | naga 3-53 
FSM_BIS_BIDDER page 3-70 
FSM_BIS_FSP page 3-71 
RTR_RSP page A-15 


If RTR_KSP.RTI = NEG and the state of #FSM_BIS = RESET (page 3-70) then: 
(see Note) 
Call SHOULD_SEND_BIS(RTR_RSP.HS_ID) (page 3-62) 
to determine whether BIS should be sent on this session. 

If SHOULD_SEND_BIS indicates that BIS should be sent then 
Call SEND_BIS(RTR_RSP.HS_ID) (page 3-53). 

Else 
Return the session to the free-session pool. 
Call DEQUEUVE_WAITING_REQUEST(RTR_RSP.HS_ID) (page 3-42) to process any waiting requests. 
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SECURITY_PROC 


This procedure checks the FMH-12, checks that the session is in the 
state to receive an FMH-12, and verifies the enciphered data found 
FMH-12. 


INPUT : SECURITY_HEADER that contains the FMH-12 (see “Appendix H. FM Header and LU 
| Services Commands" ) 


UNBIND processing if in error, state change of FSM_SCB_STATUS if OK 


Referenced procedures, FSMs, and data structures: 


RM_PROTOCOL_ERROR page 3-49 
FSM_SCB_STATUS_BIDDER page 3-68 
FSM_SCB_STATUS_FSP page 3-69 
SECURITY_HEADER page A-15 
SCB page A-9 
LUCB page A-1l 


Find the SCB corresponding to the HS process that sent the SECURITY _HEADER. 
Remove the random data sent in the RSP(BINOD) (found in SCB.RANDOM_DATA) 
from the LUCB.PENDING_RANDOM_DATA_LIST. 
If the state of #FSM_SCB_STATUS * PENDING _FMH12 (page 3-67) or 
the FMH_12 length # 10 or the enciphered random data received in the FMH-12 # 
this LU's enciphered version of the same random data then 
Call RM_PROTOCOL_ERROR(SCB.HS_ID, X'O80F6051') (page 3-49). 
Else 
Call #FSM_SCB_STATUS(R, FMH_12, UNDEFINED) (page 3-67). 


SEND_ACTIVATE_SESSION 


This procedure sends an ACTIVATE_SESSION record to LU network services to 
request activation of a new half-session. The appropriate pending session 
counts are incremented. 


LU_LNAME, the name of the partner LU; MODE_NAME, the name of the modes and the 
session polarity (FIRST_SPEAKER or BIDDER) 


ACTIVATE_SESSION to LNS 


Referenced procedures, FSMs, and data structures: 


ACTIVATE_SESSION page A-31 
MODE page A~-3 
LNS page 4-47 
LU_NAME page 3-74 
MODE_NAME page 3-74 


Find the MODE control block associated with LU_NAME and MODE_NAME. 

Create an ACTIVATE_SESSION record and set the subfields as follows: 
CORRELATOR to a unique value, LU_NAME and MODE_NAME to the LU_NAME 

and MODE_NAME inputs, and SESSION_TYPE to the session polarity input. 
Increment MODE.PENDING_SESSION_COUNT by 1. 

Increment MODE.PENDING_CONWINNERS COUNT or MODE.PENDING_CONLOSERS_COUNT by 1, 
as appropriate to the session polarity. 

Send ACTIVATE_SESSION to LNS (Chapter 4). 
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SEND_BIS 
SEND_BIS | 


This procedure causes either BIS_RQ or BIS_REPLY to be sent on the session 
identified by HS_ID. The choice of BIS_RQ@ or BIS_REPLY is dependent on the 
state of #FSM_BIS. 


HS_ID, the ID of the session 


BIS_RQ or BIS_REPLY to HS 


Referenced procedures, FSMs, and data structures: 
SEND_BIS_RQ@ page 3-54 
SEND_BIS_REPLY page 3-53 
FSM_BIS_ BIDDER page 3-70 
FSM_BIS_FSP page 3-71 
HS_ID page 3-74 


Select based on the state of &FSM_BIS (page 3-70): 
When RESET | 
Call SEND_BIS_RQ(HS_ ID) (page 3-54). 
When BIS RCVD 
Call SEND_BIS_REPLY(HS_ID> (page 3-53). 
Otherwise 
Do nothing. 


SEND_BIS_REPLY 


FUNCTION: This procedure creates a BIS_REPLY and sends it to HS. 


HS_ID, the ID of the half-session over which the BIS_REPLY will flow 


BIS_REPLY to HS 


Referenced procedures, FSMs, and data structures: 
HS 


page 6.0-3 
FSM_BIS_ BIDDER page 3-70 
FSM_BIS_FSP page 3-71 
BIS_REPLY page A-29 
MODE page A-3 
HS_ID page 3-74 


Create a BIS_REPLY record and send it to HS (Chapter 6.0). 
Call &FSM_BIS(S, BIS_REPLY, HS_ID) (page 3-70) for the session 
identified by HS_ID. 
Get addressability to the MODE control block associated with the LU and mode 
name of the session identified by HS_ID. 
Increment MODE .PENDING_ TERMINATION _CONWINNERS or MODE .PENDING_TERMINATION CONLOSERS by 1; 
as appropriate to the session. polarity. 
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SEND_BIS_RQ. 
SEND_BIS_R@ 


This procedure creates a BIS_RQ and sends it to HS. 


After the BIS_RQ is sent to the half-session, the appropriate pending terni- 


nation count is incremented. 
HS_ ID, the ID of the half-session over which the BIS_RQ will flow 
BIS _RQ to HS 


| The TERMINATION_COUNT is not decremented if the BIS_RQ was sent as a result of 
a control operator DEACTIVATE_SESSION request. 


Rateranced procedures, FSMs, and data structures: 


HS page 6.0-3 
FSM_BIS_ BIDDER page 3-70 
FSM_BIS_FSP , page 3-71 
BIS_RQ page A-29 
MODE page A-3 
HS_ID page 3-74 


éneate: @ BIS_RQ record and send it to HS (Chapter 6.0). 
Call #FSH_BIS(S, BIS_RQ, HS_ID) (page 3-70) for the session identified by HS_ID. 
Get addressability to the MODE control block associated with the LU and mode 
name of the session identified by HS_ID. 
Increment MODE . PENDING_TERMINATION_CONWINNERS or MODE .PENDING TERMINATION CONLOSERS by 1, 
as appropriate to the session polarity. 
If there is a pending CNOS operator session deactivation request for the session 
identified by HS_ID then 

Discard all pending CNOS operator session deactivation request for the session 

identified by HS_ID. 

Else (see Note) 

Decrement MODE. TERMINATION_COUNT by 7 
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SEND_DEACTIVATE_SESSION 


FUNCTION: This procedure sends a DEACTIVATE_SESSION record to LNS. 


OUTPUT: 


If the STATUS is PENDING, the appropriate pending-session counts are decre- 
mented. If STATUS is ACTIVE, a SESSION_DEACTIVATED record is created and SES5- 
SION_DEACTIVATED_PROC is called to continue’ processing the session 
deactivation. LNS does not send SESSION_DEACTIVATED in reply to DEACTI- 
VATE_SESSION. Thus, the DEACTIVATE_SESSION is created in this procedure and 
SESSION_DEACTIVATED_PROC is called to perform common processing. 


STATUS (ACTIVE or PENDING), CORRELATOR (HS_ID if STATUS = ACTIVE, else 
correlator used on ACTIVATE_SESSION request), TYPE (NORMAL, CLEANUP, ABNOR- 
MAL), and SENSE_CODE (X'00000000' if TYPE * ABNORMAL) 


DEACTIVATE_SESSION to LNS 


Referenced procedures, FSMs, and data structures: 


SESSION_DEACTIVATED_PROC page 3-58 
PS page 5.0-5 
LNS page 4-47 
SENSE_CODE page 3-75 
MODE page A-3 
DEACTIVATE_SESSION page A-31 
SCB page A-9 
SESSION_DEACTIVATED page A-21 
A~33 


SESSION_ALLOCATED page 


Select based on the value of session status: 
When PENDING 
If there is a pending session activation with a matching CORRELATOR then 
(the pending activation 1s Known to RM) 


Create a DEACTIVATE_SESSION record with DEACTIVATE_SESSION.STATUS set to PENDING; 
DEACTIVATE_SESSION.CORRELATOR set to CORRELATOR, and 
DEACTIVATE_SESSION.TYPE set to TYPE. 

If TYPE = ABNORMAL then 

Set DEACTIVATE_SESSION.SENSE_CODE to SENSE_CODE. 

Else 

Set DEACTIVATE_SESSION.SENSE_CODE to X'00000000'. 

Send the DEACTIVATE_SESSION to LNS (Chapter 4). 

Get addressability to the MODE control block associated with the LU 
and mode name of the pending active session. 

Decrement MODE.PENDING_CONWINNERS COUNT or MODE.PENDING_CONLOSERS_ COUNT by I, 
as appropriate to the session polarity. 

Decrement MODE.PENDING_SESSION_COUNT by 1. 

Discard the pending activation. 

If MODE.ACTIVE_SESSION_COUNT + MODE.PENDING_SESSION_COUNT = 0 then 

Do for each waiting request for a session to this LU name for this 
mode name: 
Create a SESSION_ALLOCATED record with RETURN_CODE set to 
UNSUCCESSFUL_NO_RETRY and send it to the PS (Chapter 5.1) 
that initiated the session request. 
Discard the waiting request. 


When ACTIVE 
If there exists an SCB where SCB.HS_ID = CORRELATOR then (session is Known to RM) 


Create a DEACTIVATE_SESSION record with DEACTIVATE_SESSION.STATUS set to ACTIVE, 
DEACTIVATE_SESSION.HS_ID set to CORRELATOR, and 
DEACTIVATE_SESSION.TYPE set to TYPE. 

If TYPE = ABNORMAL then 

Set DEACTIVATE_SESSION.SENSE_CODE to SENSE_CODE. 

Else 

Set DEACTIVATE_SESSION.SENSE_CODE to X'00000000'. 

Send the DEACTIVATE_SESSION to LNS (Chapter 4). 

Create a SESSION DEACTIVATED record with HS_ID set to CORRELATOR. 

If TYPE = NORMAL then 

Set SESSION_DEACTIVATED.REASON to NORMAL. 
Else 
Set SESSION_DEACTIVATED.REASON to ABNORMAL_NO_RETRY. 
Call SESSION _DEACTIVATED_PROC(SESSION_DEACTIVATED) (page 3-58). 
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SESSION_ACTIVATED_ ALLOCATION 


FUNCTION: This procedure handles the allocation processing for a newly activated 
first-speaker or bidder half-session. 


This procedure causes the SCB associated with the half-session and the RCB of 
a conversation for which a session was requested to point to each other. If 
PS.CONV indicated that RM is to be responsible for sending the Attach, it cre- 
ates a BID_WITH_ATTACH record from information that PS.CONV stored in the RCB 
and sends it to HS. It then creates a SESSION_ALLOCATED record, which it 
sends to PS.CONV to inform it that the session has been allocated. 


INPUT: GET_SESSION and HS_ID, the ID of the new half-session 


OUTPUT: SESSION_ALLOCATED to PS; and, if PS.CONV has indicated that RM is to send the 
Attach for the conversation, BID_WITH_ATTACH to HS 


NOTE: Since a new session is in the in-brackets state when it is activated, the 
Attach that RM sends to HS is not really a bid for the use of the session. 
After RM sends the Attach, it does not have to wait for a response from HS, 
but can report immediately to PS.CONV. Also, if PS.CONV does not request RM 
to send the Attach, RM does not send a BID_WITHOUT_ATTACH record to HS even if 
the half-session is a bidder, since the new session is already in the 
in-brackets state and no bidding is necessary. | 


“Referenced Sheceduneey FSMs, and data. strictures: 


~SET_RCB_AND_SCB_ FIELDS as page 3-61 
CONNECT_RCB_AND_SCB a page 3-39 
HS | . | : page 6.0-3 
PS a ! page 5.0-5 
FSM_RCB_STATUS_FSP page 3-73 
FSM_RCB_STATUS_BIDDER page 3-72 
GET_SESSION | | page A-26. 
HS_ID re | page 3-74 
BID_WITH_ATTACH page A-28 
SESSION_ALLOCATED . | | page A-33 
RCB , : —_— * | : | page A-7 > 


If the session identified by HS_ID is a bidder session then 
For the conversation identified by GET_SESSION.RCB_ID, 
Call #FSM_RCB_STATUS(S, GET_SESSION, UNDEFINED) (page 3-72). 
(State of #FSM_RCB_STATUS = PENDING _SCB.) 
Call SET_RCB_AND_SCB_FIELDS(GET_SESSION.RCB_ID, HS_ID) (page 3-61). 
If GET_SESSION.BID_INDICATOR = ATTACH then 
Find the RCB associated with the conversation identified by GET_SESSION.RCB_ID. 
If the security level of RCB.SECURITY_SELECT has been downgraded to NONE and 
the Attach was previously built then 
Rebuild the Attach omitting the obsolete security information. 
Create a BID_WITH_ATTACH record with the SEND_PARM fields initialized a 
the corresponding RCB.PS_TO_HS_RECORD fields. 
Send the BID_WITH_ATTACH record to HS (Chapter 6.03 see Note). 
Call CONNECT_RCB_AND_SCB(GET_SESSION.RCB_ID, HS_ID, NORMAL) (page 3-39). 
Create a SESSION. ALLOCATED record with RETURN_ CODE set to OK; and send the 
record to PS (Chapter 5.1). 
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SESSION_ACTIVATED__PROC 


This procedure performs the processing of a SESSION_ACTIVATED record from LNS. 
SESSION_ACTIVATED is received from LNS as a result of session activation ini- 


tiated by the partner LU. 


SESSION_ACTIVATED from LNS 


Referenced procedures, FSMs, and data structures: 


SUCCESSFUL_SESSION_ACTIVATION page 3-63 
SESSION_ACTIVATED page A-20 
MODE page A-3 


Get addressability to the MODE control block associated with the LU and 

wmode name of the newly activated session. 

Increment MODE .ACTIVE CONWINNERS COUNT or MODE .ACTIVE_CONLOSERS COUNT by 1, 

as appropriate to the session polarity. 

Increment MODE.ACTIVE SESSION_COUNT by 1. 
Call SUCCESSFUL_SESSION_ACTIVATION( SESSION_ACTIVATED.LU_NAME, 

SESSION_ACTIVATED .MODE_NAME, SESSION_ACTIVATED.SESSION_INFORMATION) (page 3-63). 


SESSION_ACTIVATION_POLARITY 


This procedure determines the polarity for a session activation request. 


If no session can be activated now (because LUCB.LU_SESSION_LIMIT or 
MODE.SESSION_LIMIT would be exceeded), NONE is returned. If either a 
first-speaker or bidder session could be activated, FIRST SPEAKER is returned. 
Thus, first-speaker sessions will be activated in preference to bidder ses- 


sions. 


LU_LNAME, the name of the LU to which a session is to be activated 


MODE_NAME, the name of the mode 


and 


NONE, if no session can be activated; FIRST_SPEAKER, if a first-speaker ses- 
sion can be activated; BIDDER, otherwise 


Referenced procedures, FSMs, and data structures: 


LU_NAME page 3-74 
MODE_NAME page 3-74 
MODE page A-3 


Get addressability to the MODE control block associated mith LU_NAME and MODE_NAME. 
If the number of sessions to the partner LU identified by LU_NAME and 
on mode name identified by MODE_NAME is 2 MODE.SESSION_LIMIT then 
Return with an indication that no additional sessions can be activated. 
If the total number of sessions to the partner LU identified by LU_NAME 
is greater than 0 and parallel sessions are not supported to the 
partner LU identified by LU_NAME then 
Return with an indication that no additional sessions can be activated. 
If MODE.SESSION_LIMIT - MODE.MIN_CONLOSERS_LIMIT > 
MODE .ACTIVE_CONWINNERS COUNT + MODE.PENDING_CONWINNERS COUNT then 
; Return with an indication that a first-speaker session can be activated. 
Else | 
Return with an indication that a bidder session can be activated. 
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‘SESSION_DEACTIVATED_PROC 


FUNCTION: 


Cewreree handles the processing that occurs when a session is deacti- 
vated. | , . , | 


When SESSION_DEACTIVATED.REASON = NORMAL, no processing (except destruction of 
the SCB) takes place since the decision to close down a session was mutually 
reached by the resources managers of the half-sessions via BIS protocols and 
all necessary processing has already been performed. 


When SESSION_DEACTIVATED.REASON = SON or PROTOCOL_VIOLATION and the session 
was being used by a conversation, this procedure sends a CONVERSATION_FAILURE 
record to PS.CONV. If the session was not in use, the session is removed from 
the free-session pool. Regardless of whether the session was in use, this 
procedure deletes the SCB entry for that half-session. 


SESSION_DEACTIVATED 
CONVERSATION_FAILURE to PS, or no output 


When PS.CONV receives a CONVERSATION FAILURE, it generates a DEALLOCATE_RCB 
and sends it to RM, which perforws the usual RCB deallocation processing. 


It is possible for two RCBs to be associated with the same SCB when SON 
eccurs. This happens when RM has issued a bid for the use of a bidder 
half-session and, prior to receiving the response to the bid, subsequently 
receives an Attach from the first-speaker side of the session. When RM 
receives the session outage notification, it notifies the PS that mas created 
as a result of the incoming Attach that a conversation failure has occurred. 
The PS associated with the RCB that is pending a response to the bid, however, 
never learns of the session outage. RM treats the SON as a -BID_RSP and 
attempts to satisfy the session request with another session. 


Referenced procedures, FSMs, and data structures: ; 2 
GET_SESSION_PROC page 3-45 


ACTIVATE_NEEDED_SESSIONS page 3-22 
PS page 5.0-5 
FSM_SCB_STATUS_BIDDER | page 3-68 
FSM_SCB_STATUS_FSP 7 page 3-69 
FSM_RCB_STATUS_FSP page 3-73 
FSM_RCB_STATUS_BIDDER page 3-72 
SESSION_ALLOCATED page A-33 
SESSION_DEACTIVATED page A-21 
CONVERSATION_FAILURE page A-32 
GET_SESSION | page A-26 
RM_SESSION_ACTIVATED page A-33 
SCB , | page A-9 
RCB page A-7 
MODE page A-3 
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If an SCB associated with the half-session identified by 
SESSION _DEACTIVATED.HS_ID exists then 
Get addressability to the MODE control block associated with the LU and 
mode name of the deactivated session. 
I the state of &FSM_SCB_STATUS (page 3-67) = IN_USE then 
If the RCB identified by the SCB.RCB_ID exists then 
Disconmect the PS and HS processes that are using the deactivated session. 
Create a CONVERSATION_FAILURE record with RCB_ID set to SCB.RCB_ID. 
Select based on SESSION_DEACTIVATED.REASON: 
When NORMAL 
Set CONVERSATION _FAILURE .REASON to NORMAL. 
When ABNORMAL_RETRY 
Set CONVERSATION_FAILURE .REASON to SON. 
When ABNORMAL_NO_RETRY 
Set CONVERSATION_FAILURE .REASON to PROTOCOL VIOLATION. 
Send the CONVERSATION _FAILURE record to the PS process that mas 
using the deactivated session. 
Else (session not in use by a conversation) 
Remove the session from the free-session pool. 
If there is an RCB where RCB.HS_ID = SESSION_DEACTIVATED.HS_ID and 
the state of &FSM_RCB STATUS = PENDING_SCB (page 3-72) then 
(A bid for the deactivated session is in progress: see Note 2). 
Set RCB.HS_ID to a null value. 
Call @FSM_RCB_STATUS(R, NEG_BID_RSP, UNDEFINED) (page 3-72). 
Create a GET_SESSION record from information saved in the RCB. 
Call GET_SESSION_PROC(GET_SESSION) (page 3-45) 
to retry the bid on another session. 
Decrement MODE .ACTIVE_CONWINNERS_ COUNT or MODE.ACTIVE_CONLOSERS_COUNT by 1, 
as appropriate to the session polarity. 
Decrement MODE.ACTIVE_SESSION_COUNT by 1. 
If there is a pending deactivation for the failed session then 
Decrement MODE .PENDING_TERMINATION_CONWINNERS or MODE .PENDING_ TERMINATION _CONLOSERS 
by 1, as appropriate to the session polarity. 
If SESSION _DEACTIVATED.REASON # ABNORMAL_NO_RETRY then 
Call ACTIVATE _NEEDED_SESSIONS(SCB.LU_NAME, SCB.MODE_NAME) (page 3-22). 
Xf MODE.ACTIVE_SESSION_COUNT + MODE.PENDING_SESSION_COUNT = 0 then 
Do for each waiting request for a session to (LU_NAME, MODE NAME): 
Create a SESSION_ALLOCATED record with RETURN_CODE set to UNSUCCESSFUL_NO_RETRY 
and send it to the PS (Chapter 5.1) that initiated the session request. 
Discard the waiting request. 
Do for each pending CNOS operator session activation request for a session 
to (LU_NAME, MODE_NAME ): 
Create RM_SESSION_ACTIVATED with RETURN_CODE set to ACTIVATION_FAILURE_NO_RETRY 
and send it to the PS (Chapter 5.1) that initiated the activation request. 
Discard the activation request. 
Discard the SCB. 
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SESSION_DEACTIVATION_POLARITY 


FUNCTION: This procedure determines the polarity of a session to partner LU (LU_NAME, 
| MODE_NAME) that this LU is responsible for deactivating. 


INPUT: LU_LNAME, the name of the partner LU; and MODE_NAME, the name of the mode 


OUTPUT: NONE, if this LU is not responsible for any deactivations; BIDDER, if this LU 
is responsible to deactivate a bidder session only; FIRST_SPEAKER, if this LU 
is responsible to deactivate a first speaker session only; EITHER, if this LU 
is responsible to deactivate either a first speaker or bidder session. The 
TERMINATION_COUNT is reset to 0 if it was positive and this LU is not respon- 
sible for any deactivations. 


Referenced procedures, FSMs, and data structures: 
LU_NAME 


page 3-74 
MODE_NAME page 3-74 
MODE page A-3 


Get addressability to the MODE control block associated with LU_NAME and MODE_NAME. 
If MODE.TERMINATION_COUNT = 0 then 
Return with an indication that no sessions need to be deactivated. 
Let CONWINNER_COUNT be MODE .ACTIVE_CONWINNERS COUNT + MODE.PENDING _CONWINNERS_COUNT - 
MODE .PENDING_TERMINATION_CONWINNERS. 
Let CONLOSER_COUNT be MODE.ACTIVE_CONLOSERS_COUNT + MODE.PENDING_CONLOSERS_COUNT - 
MODE .PENDING_TERMINATION_CONLOSERS. 
Select based on the following conditions: 
When CONWINNER_COUNT <= MODE.MIN_CONWINNERS_LIMIT, and 
CONLOSER_COUNT <= MODE.MIN_CONLOSERS_LIMIT 
Set MODE.TERMINATION_COUNT to 0. 
Return with an indication that no sessions need to be deactivated. 
When CONWINNER_COUNT <= MODE.MIN_CONWINNERS LIMIT, and 
CONLOSER_COUNT > MODE.MIN_CONLOSERS_ LIMIT 
Return with an indication that a bidder session needs to be deactivated. 
When CONWINNER_COUNT > MODE.MIN_CONWINNERS_LIMIT, and 
CONLOSER_COUNT <= MODE.MIN_CONLOSERS_ LIMIT 
Return with an indication that a first-speaker session needs to be deactivated. 
When CONNINNER_COUNT > MODE.MIN_CONWINNERS_LIMIT, and 
CONLOSER_COUNT > MODE .MIN_CONLOSERS_ LIMIT 
Return with an indication that a session of either polarity needs to be deactivated. 
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SET_RCB_AND_SCB_FIELDS 


FUNCTION: This procedure initializes fields in the RCB and SCB entries having the passed 
RCB and HS IDs. 


The RCB is set to point to the associated SCB (by placing the HS_ID in the 
RCB), and the SCB to point to the RCB (by placing the RCB_ID in the SCB). The 
FSMs that maintain the status of the RCB and SCB are set to the IN_USE state. 


INPUT: RCB_ID and HS_ID, the IDs of the RCB and SCB, respectively, for which fields 
are to be set 


OUTPUT: Fields in the RCB and SCB are initialized. 


NOTE : When this procedure is called from BID_RSP_PROC, RCB.HS_ID has’ already been 
initialized. (It was initialized when the BID for the session was generated. ) 
Rather than test for this condition, the field is reset to the same value. 


Referenced procedures, FSMs, and data structures: 


FSM_SCB_STATUS_BIDDER page 3-68 
FSM_SCB_STATUS_FSP page 3-69 
FSM_RCB_STATUS_FSP page 3-73 
FSM_RCB_STATUS_BIDDER page 3-72 
RCB_ID page 3-74 
HS_ID page 3-74 
SCB page A-9 
RCB page A-7 


Find the SCB associated with the half-session identified by HS_ID. 
Set SCB.RCB_ID to RCB_ID. 
Find the RCB associated with the conversation identified by RCB_ID. 
Set RCB.HS_ID to HS_ID (see Note). 
If the session identified by HS_ID is a first-speaker session then 
Call #FSM_SCB_STATUS(S, GET_SESSION, UNDEFINED) (page 3-67). 
(State of #FSM_SCB_STATUS = IN_USE.) 
Call #FSM_RCB_STATUS(S, GET_SESSION, UNDEFINED) (page 3-72). 
(State of #FSM_RCB_STATUS = IN_USE.) 
Else (bidder session) 
Call #FSM_SCB_STATUS(R, POS _BID_RSP, UNDEFINED) (page 3-67). 
(State of #FSM_SCB_STATUS = IN_USE.) 
Call #FSM_RCB_STATUS(R, POS_BID_RSP, UNDEFINED) (page 3-72). 
(State of #FSM_RCB_STATUS = IN_USE.) 


Chapter 3. LU Resources Manager 3-61 


SHOULD_SEND_BIS | 
SHOULD_SEND_BIS 


This procedure determines whether a BIS (either BIS_R@ or BIS_REPLY) should be 
sent on the session identified by HS_ID. 


HS_ID, containing the ID of the session 


‘TRUE, if BIS (BIS_RQ or BIS_REPLY) should be sent now; else FALSE 


Referenced procedures, FSMs, and data structures: 


SESSION_DEACTIVATION_POLARITY | | . page 3-60 
FSM_BIS_BIDDER oe | | page 3-70 
FSM_BIS_FSP page 3-71 
HS_ID | Os page 3-74 
LU_NAME | - | | page 3-74 
MODE_NAME | | | : page 3-74 
MODE : page A-3 


Get addressability to the MODE control block sawoc lated: with the half-session 
identified by HS_ID. 
SELECT based on the state of #FSM_BIS (page 3-70):. 
When RESET 
Call SESSION_DEACTIVATION_POLARITY(LU_NAME, NODE _NAME ) ‘(page 3-60 ) 
to determine the type of session (if. any) to deactivate. 
If the deactivation polarity = EITHER, or 
the deactivation polarity matches the session polarity then | 
If MODE.DRAIN_SELF = NO, or 
MODE .DRAIN_SELF = YES and there are no waiting requests for 
Sessions to this LU and mode name then | 
Return with an indication that BIS should be sent on this session. 
If there is a pending CNOS operator session deactivation for this session then 
; Return with an indication that BIS should be sent on this session. 
Else 
Return with an indication that BIS apenr? not be wnt on this session. 
When BIS _RCVD 
If MODE. DRAIN_SELF = NO, or 
MODE .DRAIN_SELF = YES and there are no waiting requests: for sessions 
to this LU and mode name then 
: Return with an indication that BIS should be sent on this, session. 
Else 
Return with an indication that BIS should not be sent on this session. 
When BIS_SENT (BIS already sent) 
Return with an indication that BIS should not be sunt on this session. 
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SUCCESSFUL_SESSION_ACTIVATION 


SUCCESSFUL_SESSION_ACTIVATION 


FUNCTION: This procedure handles the processing that occurs when a new session is suc- 
cessfully activated. 


When a new session is successfully activated, it comes up 'in-conversation" 
with the primary side of the session in control of the conversation. This 
procedure checks to see whether the new half-session is primary or secondary. 
If the half-session is a primary and a request is waiting, the support levels 
(i.e., sync level and conversation-level security) specified in the request 
are checked against the support levels of the session. If the support levels 
are compatible, and LU-LU verification (session-level security) is active, the 
FMH-12 to complete LU-LU verification is built and sent to the partner-LU 
resources manager; then the request is sent to SESSION_ACTIVATED_ALLOCATION 
(page 3-56) to be processed. If the support levels are not compatible, the 
request is rejected with an ALLOCATION_ERROR return code. If no requests are 
waiting, the session is returned to the free-session pool. If no request is 
waiting and LU-LU verification (session-level security) is active, the FMH-12 
is built and sent to the partner-LU resources manager, and this FMH-12 relin- 
quishes control of the session; otherwise, a YIELD _SESSION record is created 
and sent to HS to inform the secondary side of the half-session that the pri- 
mary side is relinquishing control of the conversation. The YIELD_SESSION 
record is translated into a FREE_SESSION record by the secondary half-session 
and sent to its RM. 


If the new half-session is a secondary half-session and LU-LU verification is 
active, the FSM that maintains the status of the SCB is set to indicate that 
the next record it expects to receive is an FMH-1l2 (Security). If the new 
half-session is a secondary half-session and LU-LU verification is not active, 
the FSM that maintains the status of the SCB is set to indicate that the next 
record it expects to receive is either an Attach or a FREE_SESSION. (It will 
receive an Attach if the primary half-session decides to use the session; it 
will receive a FREE_SESSION if the primary has no GET_SESSION requests waiting 
to be serviced). 


INPUT: LU_LNAME and MODE_NAME, the LU name and mode name of the newly activated ses- 
sion; and SESSION_INFORMATION (page A-36), which describes the attributes of 
the activated session 


OUTPUT: GET_SESSION to SESSION_ACTIVATED_ALLOCATION (page 3-56), YIELD_SESSION to HS, 
SESSION_ALLOCATED to PS,» or no output 


NOTE: PS.CONV stores in the RCB information that tells HS what bit settings to use 
when HS sends data out over a link. Part of the information states whether 
the data being sent to HS is the beginning of a conversation or part of an 
existing conversation. Since a new session comes up in-conversation (a fact 
that is unknown by PS.CONV), RM changes the information in the RCB to indicate 
to HS that the next record it will receive from PS.CONV will not be the start 
of a conversation. 


Referenced procedures, FSMs, and data structures: 


CREATE_SCB page 3-40 
SESSION_ACTIVATED_ALLOCATION page 3-56 
PS page 5.0-5 
HS page 6.0-3 
FSM_SCB_STATUS_BIDDER page 3-68 
FSM_SCB_STATUS_FSP page 3-69 
LU_NAME page 3-74 
MODE_NAME page 3-74 
SESSION_INFORMATION page A-36 
SCB page A-9 
RM_ACTIVATE_SESSION page A-27 
RM_SESSION_ACTIVATED | page A-33 
GET_SESSION page A-26 
YIELD_SESSION page A-30 

_ SESSION_ALLOCATED page A-33 
ENCIPHERED_RD2 page A-30 
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Call CREATE_SCB(LU_NAME, MODE_NAME, SESSION_INFORMATION) (page 3-40). 
If this is a primary half-session then 
Call #FSM_SCB_STATUS(R, SESSION_ACTIVATED, PRI) (page 3-67). 
(State of #FSM_SCB_STATUS = SESSION_ACTIVATION). 
Do until the activated session is used to service a waiting request, or 
the session is yielded. 
If a request is waiting for this LU and mode name then 
If the session does not support the security level specified by the 
waiting request then 
Downgrade the specified security level to NONE. 
If the session does not support the sync level specified by the 
waiting request then 
Create a SESSION_ALLOCATED record with RETURN_CODE set to | 
SYNC_LEVEL_NOT_SUPPORTED and send it to the PS (Chapter 5.1) associated 
with the waiting request. 
Discard the waiting request. 
Else (session support is OK) 
If LU-LU verification is active (random data is present in the SCB) then 
Create an ENCIPHERED_RD2 containing an FMH-12 (refer to Appendix H) 
initialized with the enciphered version of the random data present in the SCB. 
Set ENCIPHERED_RD2.SEND_PARM.ALLOCATE to NO. 
Set ENCIPHERED_RD2.SEND_PARM.FMH to YES. 
Set ENCIPHERED__ RD2.SEND_PARM. TYPE to FLUSH. 
Send the ENCIPHERED _RD2 to the HS (Chapter 6.0) representing 
the newly activated session. 
Create a GET_SESSION record initialized with information fro 
the waiting request. 
Call SESSION_ACTIVATED_ALLOCATION(GET_SESSION, SCB.HS_ID) (page 3-56). 
Discard the waiting request. 
Else (no waiting requests ) 
Call #FSM_SCB_STATUS(S; YIELD_SESSION, UNDEFINED) (page 3-67). 
If LU-LU verification is active (random data is present in the SCB) then | 
Create an ENCIPHERED_RD2 containing an FMH-12 initialized with the enol phered 
version of the random data present in the SCB. 
Set ENCIPHERED_RD2.SEND_PARM.ALLOCATE to NO. 
Set ENCIPHERED_RD2.SEND_PARM.FMH to YES. 
Set ENCIPHERED_RD2.SEND_PARM.TYPE to DEALLOCATE_FLUSH (yields the session). 
Send the ENCIPHERED_RD2 to the HS (Chapter 6.0) representing | 
the newly activated session. 
Else 
Create a YIELD SESSION record and send it to the HS (Chapter 6.0) 
representing the newly activated session. 
Else (secondary half-session) 
If LU-LU verification is active (random data is present in the SCB) then 
Call #FSM_SCB_STATUS(R, SESSION_ACTIVATED, SECURE) (page 3-67). 
(State of #FSM_SCB_STATUS = PENOING_FMH12). 
Else 
Call #FSM_SCB_STATUS(R, SESSION ACTIVATED; SEC) (page 3-67). 
(State of SFSM_ SCB_STATUS = PENDING_ATTACH). 
If a CNOS operator session-activation request is pending then 
Create an RM_SESSION_ACTIVATED record with RETURN_CODE set to OK and send 
it to the PS (Chapter 5.4) that originally issued 
the RM_ACTIVATE_SESSION record to RM. 


SNA Format and Protocol Reference Manual for LU Type 6.2 


TEST_FOR_FREE_FSP_SESSION 
TEST_FOR_FREE_FSP_SESSION 


FUNCTION: This procedure tests for a free first-speaker -half-session. If one is found, 
[ a new RCB is created and the support levels (conversation-level security and 
| sync level) provided by the session are checked to see if they are compatible 
with those requested in the ALLOCATE_RCB. If they are not compatible, the 
l RETURN_CODE on the RCB_ALLOCATED record is set +9 indicate an unsuccessful 
l allocation, ors, in the case of a security incompatibility, the security level 
| is downgraded to = compatible level. If the support levels are compatible, 
the half-cession is allocated to the RCB, the ID of the RCB is placed in the 

passed RCB_ALLOCATED record. 


If a free first-speaker half-session is not found, the RETURN_CODE in the 
passed RCB_ALLOCATED record is changed to indicate an unsuccessful allocation. 


INPUT: ALLOCATE_RCB and RCB_ALLOCATED. RCB_ALLOCATED was created by ALLO- 
CATE_RCB_PROC. 


OUTPUT : RCB_ALLOCATED with the RCB_ID field set to the ID of the allocated RCB, or 
with the RETURN_CODE set to UNSUCCESSFUL 


Referenced procedures, FSMs, and data structures: 


CREATE_RCB page 3-39 
SET_RCB_AND_SCB_FIELDS page 3-61 
CONNECT_RCB_AND_SCB page 3-39 
ALLOCATE_RCB page A-25 
RCB_ALLOCATED page A-32 
RCB page A-7 


If a free first-speaker session exists for ALLOCATE_RCB.LU_NAME and 
ALLOCATE_RCB.MODE_NAME then 
Call CREATE_RCB(ALLOCATE_RCB, RCB_ALLOCATED) (page 3-393. 
If the security level requested in the RCB.SECURITY_SELECT 
1s not supported by the partner LU then 
Downgrade the requested level of security to NONE. 
If the sync level requested in ALLOCATE_RCB is not supported by the partner LU then 
Set RCB_ALLOCATED.RETURN_CODE to SYNC_LEVEL_NOT_SUPPORTED. 
Else 
Call SET_RCB_AND_SCB_FIELDS(RCB_ID, HS_ID) (page 3-61). 
Call CONNECT_RCB_AND_SCB(RCB_ID, HS_ID) (page 3-39). 
Remove the session from the free-session pool. 
Else (no free first-speaker sessions). 
set RCB_ALLOCATED.RETURN_CODE to UNSUCCESSFUL. 


UNBIND_PROTOCOL_ERROR_PROC 


FUNCTION: This procedure processes an UNBIND_PROTOCOL_ERROR record from a presentation 
services component. Presentation services sends an UNBIND_PROTOCOL_ERROR to 
the resources manager when it discovers that the other side of the 
half-session has committed a protocol violation. 


INPUT : UNBIND_PROTOCOL_ERROR 


OUTPUT: The session identified by UNBIND_PROTOCOL_ERROR.HS_ID is deactivated with an 

UNBIND(X'FE') and sense data specified by UNBIND_PROTOCOL_ERROR.SENSE_CODE. 
The resources manager sends a CONVERSATION_FAILURE(PROTOCOL_VIOLATION) to 
presentation services. 


Referenced procedures, FSMs, and data structures: 
RM_PROTOCOL_ERROR page 3-49 
UNBIND_PROTOCOL_ERROR page A-28 


Call RM_PROTOCOL_ERROR( UNBIND_PROTOCOL_ERROR.HS_ID, UNBIND_PROTOCOL_ERROR.SENSE_CODE ) 
(page 3-49). 
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UNSUCCESSFUL_SESSION_ACTIVATION 


This procedure handles the processing that occurs when a new session could not 
be activated by LU network services. 


This procedure checks to see if any session has been activated for this 
(LULNAME, MODE_NAME) pair. If so, no action is taken by this procedure. The 
previously allocated session(s) will eventually be available for use by the 
transaction program(s) that requested a session. Similarly» if no sessions 
have been activated for this (LU_NAME, MODE_NAME) pair, but there are out- 
standing (pending) session activation requests that network services has not 
yet responded to, no action is taken. Some of the pending requests may suc- 
ceed in activating sessions, and these sessions can eventually be used by oth- 
er transaction programs. 


If, on the other hand, no session has been successfully activated for this 


LU_NAME and MODE_NAME and there are no other pending activation requests for 
this LU_NAME and MODE_NAME (i.e., all session activation requests have been 
responded to by network services), the procedure will send a SESSION_ALLOCATED 
record to all instances of presentation services that have requested sessions 
for this LU_NAME and MODE_NAME. 


The RETURN_CODE field of the SESSION_ALLOCATED record is set to UNSUCCESS- 
FUL_LRETRY or UNSUCCESSFUL_NO_RETRY depending on the ERROR_TYPE parameter. 


LU_NAME and MODE_NAME of the LU to which session activation was unsuccessful; 
and ERROR_TYPE, indicating RETRY or NO_RETRY 


SESSION_ALLOCATED to PS,» or no output 


PS page §.0-5 
LU_NAME page 3-74 
MODE_NAME page 3-74 
MODE page A-3 

RM_SESSION_ACTIVATED page A-33 
SESSION_ALLOCATED | page A-33 


Get addressability to the MODE control block associated with LU_NAME and MODE_NAME. 
If MODE .ACTIVE SESSION_COUNT = 0 and MODE.PENDING_SESSION_COUNT = 0 then 
Do for each waiting request for a session to (LU_NAME, MODE_NAME): 

Create a SESSION ALLOCATED record with RETURN_CODE set to 
UNSUCCESSFUL_RETRY or UNSUCCESSFUL_NO_RETRY according to 
ERROR_TYPE. 

Send the SESSION_ALLOCATED record to the PS (Chapter 5.1) 
that issued the original request. 

Discard the waiting request. 

Do for each pending CNOS operator session activation request for a 
session to (LU_LNAME, MODE NAME): 

Create an RM_SESSION_ACTIVATED record with RETURN_CODE set to 
ACTIVATION_FAILURE_RETRY or ACTIVATION _FAILURE_NO_RETRY 
according to ERROR_TYPE. 

Send the RM_SESSION_ACTIVATED record to the PS (Chapter 5.1) 
that issued the original request. 

Discard the pending session activation request. 
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#FSM_SCB_STATUS 


#FSM_SCB_STATUS is a generic FSM that main- 
tains the state of a half-session. There is 
one #FSM_SCB_STATUS for each session Known to 
the resources manager. #FSM_SCB_STATUS is 
initialized to either FSM_SCB_STATUS_BIDDER 
or FSM_SCB_STATUS_FSP, depending on the ses- 
sion polarity, when the resources manager 
becomes aware of the existence of anew ses- 
Sion. This initialization occurs in CRE- 
ATE_SCB (page 3-40). 


The states of FSM_SCB_STATUS_BIDDER and 
FSM_SCB_STATUS_FSP are: 


e SESSION ACTIVATION--the initial state, 
following activation of the session 


e FREE--the session is free for use by a 
conversation 

@ PENDING ATTACH--the session is in the 
in-brackets state and the local LU is 
waiting for an Attach FM header from the 
remote LU 

e IN USE--the session is in use by a con- 
versation 

e PENDING FMH12--the session 1s waiting for 
the Security FM header from the remote LU 
before beginning normal Attach processing 


The first input denotes whether a record has 
been sent (S) or received (R) by RM, and the 
second input denotes the particular record 
type. PRI (primary), SEC (secondary), and 
SECURE (session-level security) are 
half-session attributes. 
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FSM_SCB_STATUS_BIDDER 


FUNCTION: To remember the status of a bidder half-session 
NOTES: 1. The initial state of this FSM is SESSION_ACTIVATION. 


2. When HS on the bidder side of a half-session receives an Attach, it converts 
the Attach into separate BID and ATTACH_HEADER records. RM (bidder side) 
always sends a positive BID_RSP to HS (unless a protocol error has occurred). 
HS (bidder side) discards the BID_RSP and then sends the ATTACH_HEADER to RM. 
RM on the first-speaker side does not generate the separate BID and 
ATTACH_HEADER records, and furthermore does not expect a BID_RSP since a 
first-speaker half-session always gains access to the session. 


A YIELD_SESSION will move the FSM from SESSION_ACTIVATION state to the IN_USE 
state. A FREE_SESSION is expected from the half-session to then change the 
state to FREE. . 


STATE NAMES---->]| SESSION 
| ACTIVATION 
INPUTS STATE NUMBERS-->| 01 


R» POS_BID_RSP 


| R, BID 
R, ATTACH 
R, FMH_12 


R, FREE_SESSION 
S, YIELD_SESSION 


R, SESSION_ACTIVATED, PRI 
R, SESSION_ACTIVATED, SEC 
R,» SESSION_ACTIVATED, SECURE 


PENDING PENDING 
ATTACH FMH12 
03 05 


ik 7 j 
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FSM_SCB_STATUS_FSP 


FUNCTION 


NOTES: 


INPUTS 


l. 


2. 


To remember the status of a first-speaker half-session 


The initial state of this FSM is SESSION_ACTIVATION. 


A YIELD_SESSION will move the FSM from SESSION_ACTIVATION state to the IN_USE 
state. A FREE_SESSION is expected from the half-session to then change the 
state to FREE. 


STATE NAMES---->] SESSION PENDING PENDING 
ACTIVATION ATTACH | FMH12 
STATE NUMBERS-->] 01 


S, GET_SESSION 


R, BID 
R, ATTACH 
R, FMH_12 


S,» YIELD_SESSION 


R,» SESSION_ACTIVATED, PRI 
R, SESSION_ACTIVATED, SEC 
R, SESSION_ACTIVATED, SECURE 


Chapter 3. LU Resources Manager 3-69 


#FSM_BIS The states of FSM_BIS_BIDDER and FSM_8IS_FSP 
ares 


$FSM_BIS is a generic FSM that maintains the ® RESET--the initial state; BIS has been 


state of the BIS protocol for a half-session. neither sent nor received 

There is one #FSM_BIS for each session Known e BIS SENT~--the local LU has sent BIS 

to the resources manager. &FSM_BIS is ini- ® BIS RCVD--the local LU has received BIS 

tialized to either FSM_BIS_BIDDER 3 or ® CLOSED--the local LU has both sent and 

FSM_BIS_FSP, depending on the session polari- received BIS 

ty, when the resources manager becomes anare | 

of the existence of a nen session. This The first input denotes whether a record has 

initialization occurs in CREATE_SCB (page been sent (5S) or received (R) by RM, and the 

3-40). second input denotes the particular record 
type. 


FSM_BIS_BIDDER 


To remember the status of a bidder half-session with respect to BIS_RQ and 
BIS_REPLY 


The initial state of this FSM is RESET. 


After BIS_RQ and BIS_REPLY have been exchanged over a session, this FSM will 
be in the CLOSED state, indicating that the session is being deactivated. The 
CLOSED state is a terminating state, in that the FSM will not leave this state 
until it (along with its corresponding SCB) is destroyed. 


Referenced procedures, FSMs, and data structures: | 
SEND_DEACTIVATE_SESSION page 3-55 


CHECK_FOR_BIS_REPLY page 3-38 
BIS_RACE_ LOSER | page 3-35 
RM_PROTOCOL_ERROR page 3-49 
HS_ID page 3-74 


STATE NAMES~---~> 


RESET BIS BIS CLOSED 
SENT RCVD 
| STATE NUMBERS-->1 01 02 03 04 
S$, BIS_R@ 2 / 7 ¢ 
R,» BIS_REPLY >( ERROR) 4(A) >C ERROR ) / 
R, BIS_RQ 3(B) 4(C) >CERROR ) vA 
S, BIS_REPLY ? / & 7 


Call SEND _DEACTIVATE_SESSION( ACTIVE, HS_ID, NORMAL» X‘'00000000') (page 3-55). 


Bo Call CHECK_FOR_BIS_REPLY(HS_ID) (page 3-38). 


Call BIS_RACE_LOSER(HS_ID) (page 3-35). 
ERROR 


Call RM_PROTOCOL_ERROR(HS_ID, X'20100000') (page 3-49). 
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FSM_BIS_FSP 
FSM_BIS_FSP 


FUNCTION: To remember the status of a first-speaker half-session with respect to BIS_RQ 
and BIS_REPLY 


NOTES: 1. The initial state of this FSM 1s RESET. 


2. After BIS_RQ and BIS_REPLY have been exchanged over a session, this FSM will 
be in the CLOSED state, indicating that the session is being deactivated. The 
CLOSED state is a terminating state, in that the FSM will not leave this state 
until it (along with its corresponding SCB) is destroyed. 


Referenced procedures, FSMs, and data structures: 


SEND_DEACTIVATE_SESSION page 3-55 
CHECK_FOR_BIS_REPLY page 3-38 
RM_PROTOCOL_ERROR page 3-49 
HS_ID page 3-74 


STATE NAMES----> 


S, BIS_RQ / / 
R, BIS_REPLY >( ERROR) GCA) >( ERROR) 
R, BIS_RQ 3(B) >( ERROR) 
S, BIS_REPLY / 4 


OUTPUT | FUNCTION 
CODE 


aa Call SEND_DEACTIVATE_SESSION( ACTIVE, HS_ID, NORMAL, X'00000000') (page 3-55). 


RESET BIS BIS CLOSED 
SENT RCVD 
INPUTS STATE NUMBERS-->; 01 02 03 04 
2 
/ 


Call CHECK_FOR_BIS_REPLY(HS_ID) (page 3-38). 


ERROR Call RM_PROTOCOL_ERROR(HS_ID, X'20100000') (page 3-49). 


Chapter 3. LU Resources Manager 3-71 


#FSM_RCB_STATUS 


#FSM_RCB_STATUS ‘s a generic FSM that main- 
tains the state of a conversation resource. 
The: e 1s one #FSM_RCB_STATUS for each conver- 
sation Known to the resources manager. 
#FSM_RCB_STATUS is initialized to either 
FSM_RCB_STATUS_BIDDER or FSM_RCB _STATUS_FSP, 
depending on the polarity of the underlying 
session, resources manager creates the con- 
versation resource. This initialization 
occurs in BIDDER_PROC (page 3-34), CREATE_RCB 
(page 3-39), and PS_CREATION_PROC (page 
3-47). 


The states of FSM_RCB_STATUS_BIDDER and 
FSM_RCB_STATUS_FSP are: 


FSM_RCB_STATUS_BIDDER 


FUNCTION: 
half-session 


®  FREE--the initial state; the conversation 
is Inactive 

® IN USE--the conversation is in progress 

e PENDING SCB (BIDDER only)--the conversa- 
tion is awaiting allocation of a session, 
pending receipt of RSP(Bid) , 

e INITIAL (FSP only)--the conversation is 
the initial conversation established by 
UPM_IPL 


The first input denotes whether a record has 
been sent (S) or received (R) by RM, and the 
second input denotes the particular record 
type. HS (half-session) and UPM (undefined 
protocol machine) represent the sender of the 
Attach. | 


To remember the status of a conversation resource associated with a bidder 


NOTES: The initial state of this FSM is FREE. 


The RCB may be in the FREE state when a DEALLOCATE_RCB is issued if RM discov- 
ers that an ALLOCATION_ERROR exists before it attempts to get a session for 


the transaction program. 


The ALLOCATION_ERRORs that can occur in this situ- 


ation are ALLOCATION_FAILURE_* and SYNC_LEVEL_NOT_SUPPORTED_BY_LU. 


INPUTS 


R, POS _BID_RSP 
R, NEG _BID_RSP 


R, ATTACH, HS 


PENDING 
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FSM_RCB_STATUS_FSP 
FSM_RCB_STATUS_FSP 


To remember the status of a conversation resource associated with a 
first-speaker half-session 


The initial state of this FSM is FREE. 
The RCB may be in the FREE state when a DEALLOCATE_RCB is issued if RM discov- 
ers that an ALLOCATION_ERROR exists before it attempts to get a session for 


the transaction program. The ALLOCATION_ERRORs that can occur in this situ- 
ation are ALLOCATION_FAILURE_* and SYNC_LEVEL_NOT_SUPPORTED_BY_LU. 


INITIAL 
03 


STATE NAMES----> 
STATE NUMBERS--> 


R, ATTACH, HS 
R, ATTACH, UPM 


S, ALLOCATE_RCB 
S, GET_SESSION 


S$, DEALLOCATE_RCB 
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LOCAL DATA STRUCTURES 


3-74 


LU_NAME 


LU_LNAME: LU name 


MODE_NAME 


MODE_NAME: mode name 


HS_ID: half-session identifier 


RCB_ID 


RCB_ID: conversation resource identifier 


TCB_ID 


TCB_ID: TP-PS process identifier 


SNA Format and Protocol Reference Manual for LU Type 6.2 


SENSE_CODE 


SENSE_CODE: 4-byte sense data 
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CHAPTER 4. LY NETWORK SERVICES 


PU < Network 
Services V Vy i 
@ 
PNCP-LU LU-LU 
Hal f-Session Hal f-Session 
Services Manager 
A LU 
| l 
Vv Vv 
Path Control 
Notes: 


® Only the LU components having a protocol boundary with LU network services are shown. 
@¢ 8 6The PNCP-LU half-session is present only in peripheral nodes. 


Figure 4-1. Protocol Boundaries Between LU Network Services and Other Components 


GENERAL DESCRIPTION 


This chapter describes the network services 
component within an LU. Figure 4-1 shows the 
LU ss network = services component and its 
relation to other components within the node. 
The arrows joining the components represent 
the protocol boundaries that exist between 


the LU network services component and the | 


other components. 


The LU network services component (abbrevi- 
ated UNS) initiates and terminates LU-LU ses- 
sions in response to requests from the 
resources manager and from the remote LU. 
LNS also activates and deactivates CP-LU ses- 
sions. 


The initiation and termination of LU-LU ses- 
sions involves exchanging session-services 
RUs between the LU and a CP, and exchanging 
session-control RUs between the LU and a 
partner LU. The exchange of session-control 
RUs performs the actual activation and deac- 
tivation of the LU-LU sessions. The exchange 
of session-services RUs precedes and follows 
the activation and deactivation of the LU-LU 
sessions. 


Session-control requests and responses are 
sent on the expedited flow with the RU cate- 
gory indicating session control (SC). 
Session-control RUs ara sent field-formatted. 
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Full details of the formats for 
field-formatted RUs are given in "Appendix E. 


Request/Response Unit (RU) Formats". 


Session-services 


requests and responses 
belong to the network-services (NS) format of 
RUs. All session-services requests and 


responses are sent on the normal flow with 
the RU category indicating FM data (FMD). 


Session-services requests flowing between an 
LU and a CP may be field-formatted (RH Format 
indicator set to 0) or character-coded (RH 
Format indicator set to 1). Character-coded 
requests contain RUs consisting of character 
strings that can be translated into equiv- 
alent field-formatted RUs. A_ translation 
protocol is provided by the CP. The format 
of character-coded requests and the trans- 
lation rules that apply to them = are 
implementation-dependent and are not defined 
in this book. 


All nodes contain a CP. The CP in a type-5 
(subarea) node is called a system services 
control point (SSCP). The CP in a peripheral 
node is called a peripheral node control 
point (PNCP). When initiating or terminating 
an LU-LU session, the LU exchanges session 
services RUs with one CP—the one configured 
to mediate the initiation or termination of 
the particular LU-LU session. 


When the LU-LU session is between subarea 
nodes or between a subarea node and a periph- 
eral node, an SSCP mediates the session ini- 
tiation or termination. In this case, the 
LU-LU session uses a route in a subarea 
path-control network. When the LU-LU session 
is between peripheral nodes, the PNCP in one 
of the two nodes mediates the session initi- 
ation or termination. In this case, the 
LU-LU session does not use subarea 
path-control, but instead uses a direct route 
between the two peripheral nodes. 


When initiating and terminating SSCP-mediated 
sessions, the session-services RUs~ are 
exchanged between the LU and the SSCP over an 
SSCP-LU session. Similarly, for 
PNCP-mediated sessions, the RUs are exchanged 
between the LU and the PNCP over a PNCP-LU 
session within the peripheral node, and no 
session-services RUs flow outside the node. 


Activation and deactivation of a CP-LU ses- 
sion is accomplished by exchanging 
session-control RUs between the CP and LNS. 
The CP-LU session is activated prior to ini- 
tiating any LU-LU sessions for which that CP 
is the mediator. 


LNS informs the CP—either an external SSCP 
or the internal CP—about the characteristics 
and current status of the LU during the acti- 
vation of the CP-LU session. LNS negotiates 
session parameters with the LNS component in 
the partner LU during LU-LU session acti- 
vation. ; 


The LU resources manager (abbreviated RM) in 
one of the two LUs directs the activation or 
deactivation of an LU-LU session. Upon com- 
pletion of the activation or deactivation, 


LNS in each of the two LUs inforns its local 
RM that the LU-LU session has been activated 
or deactivated. 


LNS is aware of the type of node (peripheral 
or subarea) in which the LU resides and of 
the identity of the CP-mediator (PNCP or 
SSCP) for each LU-LU session. LNS absorbs 
differences in protocols that result from the 
type of node in which it resides. This per- 
mits other components of the LU to be inde- 
pendent of the node type. LLNS also isolates 
the other components from the CP-mediator for 
the LU-LU sessions, and thus the _ rout- 
ing—subarea path-control or direct—used for 
the sessions. | 


OVERVIEW OF CP-LU SESSION ACTIVATION 


The CP directs the LU to activate a CP-LU 
session by sending it an ACTLU request. The 
PU in the node receives the ACTLU request, 
determines which LU is to receive’ the 
request, and passes the request to the LNS 
component in the LU. LNS processes the ACTLU 
request and activates a CP-LU half-session. 
LNS's processing of the ACTLU- request 
includes the following: 


® Check for error conditions associated 
with the request, and for conditions that 
prevent activation of the session. 


® Notify path control within the node that 
a new session is being activated. 


@® Send an ACTLU response to the CP. 


° Create and initialize the half-session 
process for the LU's side of the CP-LU 
session. 


After the CP-LU session is activated, the LU 


can initiate LU-LU sessions for which that CP 


is the mediator. 


OVERVIEW OF CP-LU SESSION DEACTIVATION 


The CP directs the LU to deactivate a CP-LU 
session by sending it a DACTLU(Normal) 
request (in contrast to a DACTLU(SON) result- 
ing from session outage). The PU in the node 
receives the DACTLU request, determines which 
LU is to receive the request, and passes the 
request to the LNS component in the LU. LNS 
processes the DACTLU request and deactivates 
the CP-LU half-session. LNS's processing of 
the DACTLU request includes the following: 


® Check for error conditions associated 
‘with the request. 


® Send a DACTLU response to the CP. 


® Notify path control within the node that 
the session has been deactivated. 


® Reset all LU-LU half-sessions for which 
this CP was the session-initiation 
mediator. | 
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® Destroy the half-session process for the 
LU's side of the CP-LU session. 


When. the LU receives a DACTLU(SON) request, 
LNS performs similar processing except that 
it does not reset any LU-LU half-sessions. 


After the CP-LU session is deactivated, the 
LU cannot initiate LU-LU sessions for which 
that CP is the mediator. 


OVERVIEW OF LU-LU SESSION INITIATION 


RM directs the LU to activate an LU-LU ses- 
sion by sending LNS an ACTIVATE_SESSION 
record across an protocol boundary. LNS 
processes the ACTIVATE_SESSION record and 
initiates an LU-LU half-session. The LNS 
components in the two LUs activate the LU-LU 
session by exchanging a BIND request and 
response. LNS's processing of the ACTI- 
VATE_SESSION record, which constitutes its 
part of the LU-LU. session initiation, 
includes the following: 


® Check for conditions that prevent acti- 
vation of the session. 


e Obtain the identification of the CP that 
will mediate the LU-LU session initi- 
ation. 


e Send an INIT-SELF request to the CP. The 
request directs the CP to mediate the 
initiation of the LU-LU session. 


e Obtain the session parameters and acti- 
vate the LU-LU session, as follows: 


- If the LU is to be the primary for 
the session, then receive a CINIT 
request from the CP, build a BIND 
request that Specifies the desired 
parameters for the LU-LU session, 
send the BIND request to the partner 
(secondary) LU, and receive the BIND 
response. 


- If the LU is to be the secondary for 
the session, then receive the BIND 
request, build a negotiated BIND 
response that specifies the agreed-to 
parameters for the LU-LU session, and 
send the BIND response to the partner 
(primary) LU. 


® Notify path control within the node that 
a new session is being activated. 


e Create and initialize the half-session 
process for this LU's side of the LU-LU 
session. 


® Notify the CP that a new LU-LU session is 
activated. 


® Notify RM that the requested LU-LU ses- 
Sion is active. 


The partner LU to the one initiating the 
LU-LU session is directed to activate the 
LU-LU session by means of receiving either 


the CINIT request when it is the primary LU, 
or the BIND request then it is the secondary 
LU. Its processing following receipt of the 
CINIT or BIND request is similar to the proc- 
essing just outlined. However, instead of 
replying to RM with a notification that a 
requested session is activated, LNS informs 
RM that an LU-LU session has been activated 
at the direction of the remote LU. After the 
LU-LU session is activated, the two LUs can 
allocate the session for conversations 
between transaction programs. 


The parameters used for the LU-LU session and 
carried in the BIND request and response have 
the following sources: 


® Fixed parameters: These have fixed val- 
ues for all BIND requests and responses 
for LU 6.2 sessions. 


® Implementation-dependent parameters: 
These have values that are determined 
during the design of the implementation 
of the node. 


e User installation-specified parameters: 
These have values that are determined by 
the user at the node's installation. 


® CINIT parameters: These have values tak- 
en from the CINIT request and sent in the 
BIND request. 


OVERVIEW OF LU-LU SESSION TERMINATION 


RM directs the LU to deactivate an LU-LU ses- 
sion by sending LNS a DEACTIVATE_SESSION 
record across an internal protocol boundary. 
LNS processes the DEACTIVATE_SESSION record 
and terminates the LU-LU half-session. The 
two LUs deactivate the LU-LU session by 
exchanging an UNBIND request and response. 
LNS's processing of the DEACTIVATE_SESSION 
record, which constitutes its part of the 
LU-LU session termination, includes the fol- 
lowing: 


® Send an UNBIND request to the partner LU 
and receive the UNBIND response. 


® Notify path control within the node that 
the session has been deactivated. 


© Notify the CP that the LU-LU session has 
been deactivated. 


® Destroy the half-session process for this 
LU's side of the LU-LU session. 


The partner LU to the one terminating the 
LU-LU session is directed to deactivate the 
LU-LU session by means of receiving § the 
UNBIND request. Its processing following 
receipt of the UNBIND request is similar to 
the processing just outlined. However, after 
the session has been deactivated, LNS informs 
RM that an LU-LU session has been deactivated 
at the direction of the remote LU. 


RM may request deactivation of an LU-LU ses~ 
sion that is pending activation, that is, a 
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session for which LNS has sent an INIT-SELF 
request to the CP and has not yet received 
the CINIT or BIND request for the session. 
LNS terminates a pending-active session by 
sending the CP a TERM-SELF request. The 
TERM-SELF request directs the CP to terminate 
the pending-active session without completing 
the initiation. LNS terminates the 
pending-active session when it = sends 


 JERM-SELF, without waiting for the response. 


SESSION OUTAGE AND SESSION REINITIATION 


An active session between two LUs may be 
interrupted by a failure of one or both of 
the LUs, by a reset of one or both of their 
half-sessions, or by a failure of the path 


NETWORK CONTEXT FOR SESSION INITIATION AND TERMINATION 


4-4 


Certain terms are used that relate to LU-LU 
session initiation and termination. The 
terms are used to identify the roles of the 
LUs in the context of initiating and terni- 
nating LU-LU sessions. The terms are: 


Initiating LU (ILU) 
Terminating LU (TLU) 
Origin LU (OLU) 
Destination LU (DLU) 
Primary LU (PLU) 
Secondary LU (SLU) 


@#e@8e8@¢8 @ 


The abbreviations in parentheses following 
the terms appear in the format descriptions 
of the session-services and session-control 
RUs given in “Appendix £. Request/Response 
Unit (RU) Formats" and are also used through- 
out this chapter. 


ILU AND TLU 


ILU and TLU refer to the role of an LU in 
initiating and terminating a particular LU-LU 
session. The LU that initiates an LU-LU ses- 
sion is the ILU, and the LU that terminates 
an LU-LU session is the TLU. The ILU or TLU 
way be one of the session partners, in which 
case the LU the CP an INIT-SELF or TERM-SELF 
request, respectively. The ILU or TLU may, 
instead, be a third-party LU that is not one 
of the session partners. Session initiation 
or termination by a third-party LU applies 
only to SSCP-mediated sessions. Details of 
the formats and protocols for third-party LUs 
are not described. 


The ILU or TLU may reside in either a subarea 
node or peripheral node for SSCP-mediated 
sessions, except that a third-party ILU or 


that connects the LUs. This interruption 
causes @ session » and notification to 
the LU of the session outage is referred to 
as session » or SON. When 
LNS receives a session outage notification, 
it notifies RM for each LU-LU session 
affected by the session outage. 


When session outage occurs, RM may direct LNS 
to reinitiate the sessions. For example, RM 
requests session reinitiation when the ses- 
sion outage causes the muber of active ses- 
sions for which the LU is the contention 
winner to decrease below a minimum nunber. 
See "Chapter 3. LU Resources Manager" and 


"Chapter 5.4. Presentation Serv- 
ices--Control-Operator Verbs" for more 
details. 


TLU always resides in a subarea node. The 
ILU or TLU resides in a peripheral node for 
PNCP-mediated sessions. 


OLU AND DLU 


OLU and DLU refer to the role of an LU and 
its CP during session initiation or termi- 
nation. An ILU or TLU that is one of the 
session partners is also the OLU. An LU 
whose SSCP receives an initiation or termi- 
nation request from a third-party LU is the 
OLU. The OLU's session partner is the DLU. 
The INIT-SELF includes the name of the DLU. 


The OLU or DLU may reside in either a subarea 
node or peripheral node for SSCP-mediated 
sessions. The OLU or OLU reside in a periph- 
eral node for PNCP-mediated sessions. 


PLU AND SLU 


PLU and SLU refer to the role of an LU in 
providing, respectively, primary or secondary 
half-session control for an LU-LU session of 
which it is a partner. The PLU sends the 
BIND request and receives the BIND response. 
Correspondingly, the SLU receives the BIND 
request and sends the BIND response. 


The PLU resides in a subarea node for 
SSCP-mediated sessions, and a peripheral node 
for PNCP-mediated sessions. The SLU may 
reside in either a subarea node or peripheral 
node for SSCP-mediated sessions; it resides 
in a peripheral node for PNCP-mediated ses- 
sions. 


SNA Format and Protocol Reference Manual for LU Type 6.2 


RU PARAMETERS 


The following sections define some parameters 
that are common to many session-services and 
session-control field-formatted RUs. 


NETWORK NAME 


A network name is the name by which an LU is 
Known throughout an individual SNA network. 
Network names are unique within an individual 
network. 


FULLY QUALIFIED NETWORK NAME 


6 futly qualified network name is the name by 
which an LU is Known throughout an inteccon- 
nected SNA network. An interconnected net- 
work comprises one or =*more_ = individual 
networks. A fully qualified network name 
consists of a network identifier and a net- 
work LU name. Fully qualified network names 
are unique throughout an interconnected net- 
work. 


UNINTERPRETED NAME 


An uninterpreted name is any name by which an 
LU and its CP know another LU for the purpose 
of initiating an LU-LU session. It can be 
used by an ILU to identify a DLU. An unin- 
terpreted name requires interpretation (or 
transformation) by the CP in order to yield 
the network name. An uninterpreted name may 
be the same as a network name. 


USER REQUEST CORRELATION 


A user request correlation (URC) field 
denotes a variable-length byte string con- 
sisting of a Length field and the URC itself. 
It is assigned by the end user for placement 
in an INIT-SELF or TERM-SELF request. Its 
usage allows subsequent requests involving 
the ILU or TLU to be associated with the 
INIT-SELF or TERM-SELF request. The associ- 
ated requests either contain a field specif- 
ically defined for this purpose or use a 
session key (discussed under ''Session Key and 
Session Key Content''). 


MODE NAME 


The CP has information about the LU that aids 
in the construction of the BIND image (car- 
ried in CINIT). The CP derives the BIND 
image contents from the mode name. The LU 
supplies the mode name in INIT-SELF requests. 


In addition to the BIND image, the CP uses 
the mode name to select a class of service 
for the LU-LU session. As an example, some 


sessions may require service with a fast 
response time Cimplying» for example, 
high-speed links, shortest distance, and high 
transmission priority), while others = may 
require large bandwidth or more secure paths. 
Different mode names can be defined in order 
to select the different classes of service. 


Using the mode name, a transaction program is 
able to select for a conversation the session 
characteristics it desires. Then, when allo- 
cating the conversation to a session, LRM 
suoplies the wode name for the session in its 
session-activation request to LNS. 


BIND image and the 
the mode name 15 
and 


The derivation of the 
class of service from 
implementation-dependent 
installation-speci fied. 


SESSION KEY AND SESSION KEY CONTENT 


There are various ways of denoting which 
LU-LU session a request 1s referring to; this 
may be, for example, by name pair, address 
pair, or by the URC. The session key and 
session key content permit requests that 
refer to sessions to do so in one or more 
ways. The session Key content contains the 
particular fields denoted by the session key. 
The format description, in “Appendix § E. 
Request/Response Unit (RU) Formats", of a 
request specifying a session Key and session 
key content also specifies the keys permitted 
(or required) with that request. 


When the session key content contains a name 
pair or an address pair, it is an ordered 
pair. The order is (PLU,SLU) unless other- 
wise specified by the session key definition. 
Exceptions exist for requests whose formats 
use the LU designations, OLU and DLU. For 
these formats the session Key content order 
is (OLU,DLU) and other related fields specify 
which is PLU and which is SLU. 


LU-LU VERIFICATION DATA 


Random data and enciphered data are used for 
LU-LU verification. Random data is randomly 
generated data of symbol-string type 6G. 
Enciphered data is the enciphered version of 
the random data. 


If LU-LU verification is active, BIND and 
RSP(BIND) will contain 8 bytes of random data 
generated by the sender for LU-LU verifica- 
tion. RSP(BIND) will also contain 8 bytes of 
enciphered data for the same purpose. The 
secondary LU submits the random data received 
in the BIND request along with the LU-LU 
password to the Data Encryption Standard 
(DES) algorithm to obtain enciphered data. 
This enciphered data is inserted in the 
RSP(BIND) along with new random data. When 
the primary LU receives the RSP(BIND), it 
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ification of a 


compares the received enciphered data with a 
copy of the same random data that it has also 
enciphered using its copy of the LU-LU pass- 
word and the DES algorithm. If they are 
identical, the primary LU has verified that 
the SLU has the correct LU-LU password. 


Up to this point, processing has been done by 
the LU network services component of each LU. 
LNS components in the primary and secondary 
LUs send to their respective resources manag- 
er components a record that contains the ran- 
dom data from the RSP(BIND). The primary 
LU's RM enciphers the random data using the 
LU-LU password and the DES algorithm, inserts 
it in a Security FM header, and sends it to 
the secondary's RM component The received 
enciphered data is compared with the second- 
ary LU's version of the enciphered data. If 
they are identical, the secondary LU has ver- 
ified that the primary LU has the correct 
LU-LU password. 


SPECIFICATION OF RU PARAMETERS 


Throughout the descriptions of the RUs in 
this chapter, reference is made to the spec- 
parameter. Speci fication 
refers to a specific value that is supplied 
for the parameter when the RU is being buist, 
prior to its being sent. 


IMPLEMENTATION-DEPENDENT PARAMETERS 


Throughout the descriptions of the RUs in 
this chapter, reference is made to 


implementation-dependent parameters. 
Implementation-dependent means that the par- 


ticular value, or values, that a parameter of 


an RU can take on is determined by implemen- 
tation design. 


INSTALLATION-SPECIFIED PARAMETERS 


Throughout the descriptions of the RUs in 


this chapter, reference is made to 
installation-speci fied parameters. 


Installation-specified means that the partic- 
ular values or values, that a parameter of an 
RU can take on is determined by the user at 
the node installation. 
Installation-specified values can be estab-~ 
lished during system configuration of a node, 


or later during its operation. The method 
for establishing values of 
installation-speci fied parameters is 


implementation-dependent. 
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SESSION-SERVICES RU'S 


This section describes the session-services 
requests and extended responses that LNS 
sends and receives. These RUs belong to the 
FM-data category of network-services RUs. 


Preceding the individual descriptions is a 
list of the RUs, grouped according to their 
use. Listed with each RU is the number of 
the page on which the description of the RU 
begins. In addition, Figure 4-2 on page 4-8 
Shows the RH formats for the session-services 
requests and responses that LNS sends and 
receives. 


Each RU description includes the RU flow and 
a discussion of the function and use of the 
RU. Refer to “Appendix E. Request/Response 
Unit (RU) Formats" for specifications of the 
RU formats. 


Session-services RUs pertaining to LU-LU ses- 
sion initiation are: 


RU Page 


INITIATE-SELF CINIT-SELF) 4-9 
CONTROL INITIATE (CINIT) 4-9 


RSP(CINIT) 4-10 
SESSION STARTED (SESSST) 4-11 
BIND FAILURE (BINDF } 4-11 


RUs pertaining to session termination are: 


RU Page 


TERMINATE-SELF (TERM-SELF) 4-11 
CONTROL TERMINATE (CTERM) 4-12 
CLEAN UP SESSION (CLEANUP) 4-12 
SESSION ENDED (SESSEND } 4-13 
UNBIND FAILURE (CUNBINDF ) 4-13 


The following RU pertains to reporting the 
status of the session initiation or termi- 
nation, or of the LU: 


RU Page 


NOTIFY 4-14 
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INIT-SELF | SESSST 
CINIT SESSENO 
TERM-SELF | BINDOF 

CTERMN | UNBINDF 


Session-Services RU ——> 


CLEANUP 
NOTIFY 


Header Indicators 


| RH Byte 0 Bit 0 
Bits 1-2 
Bit 
Bit 
Bit 
Bit 
Bit 


RH Byte 1 Bit 
Bit 
Bit 
Bit 
Bits 
Bit 
Bit 


DRIT 
reserved 


4-5 


RH Byte 2 


MOM PUN! Oise wwe Go }] WO VL vl 


RH Byte 0 Bit 0 
Bits I- 2 
Bit 
Bit 
Bit 
Bit 


RH Byte I Bit 


reserved 
DR2I 

RTI 
reserved 
ml 


RH Byte 2 Bits 0-7 00000000 ae: 


Vv 
1. XX means either XX or ~XX. 
2. See “Appendix D. RH Formats" for complete RH descriptions. 


L 
3. The TH formats are not described in this book. 


4. SESSST, SESSEND, BINOF, and UNBINOF are sent with no-response indicated. 


UN & Oo sala 


Figure 4-2. Session-Services RH Formats 
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INITIATE-SELF CINIT-SELF ) 


Flow: From ILU to CP (Normal) 


INIT-SELF requests that the CP assist in the 
initiation of a session between the LU send- 
ing the request (the ILU, which also becomes 
the OLU) and the LU named in the request (the 
DLU). The INIT-SELF indicates 
definite-response requested. 


For SSCP-mediated sessions, the ILU may be 
located in either a subarea node or peripher- 
al node. For PNCP-mediated sessions, the ILU 
is located in a peripheral node. 


The INIT-SELF request contains, among other 
parameters, the uninterpreted nawe of the DLU 
with which the session is to be initiated, 
the mode name for the session, and a URC for 
the initiation request. 


The DOLU may be unavailable for activation of 
an LU-LU session. This occurs when the OLU 
is not currently able to comply with the 
PLUISLU specification, or when it is at its 
session limit. At CP-LU session activation 
time, the LU informs the CP of its availabil- 
ity by means of control vector X'0C' carried 
in its positive response to ACTLU. Subse- 
quently, during the active CP-LU session, the 
LU reports changes in its availability (such 
as changes in its PLUISLU capability or its 


CONTROL INITIATE (CINIT) 


F low: From CP to PLU (Normal) 


CINIT requests that the LU receiving the 
request attempt to activate an LU-LU session 
with the LU named in the request. The LU 
receiving CINIT is the PLU for the session. 
The LU named in the request is the SLU for 
the session. The CINIT indicates 
definite-response requested. 


For SSCP-mediated sessions, the PLU is 
located in a subarea node. For PNCP-mediated 
sessions, the PLU is located in a peripheral 
node. 


The parameters in CINIT include the suggested 
parameters for the BIND, which represent the 
BIND image. The BIND image parameters are 
selected by the CP. Selection is based on 
optional implementation-dependent and 
installation-specified parameters for the PLU 
or SLU to which the respective parameters 
apply» and on the mode-name parameter in the 
INIT-SELF associated with the CINIT. 


The PLU inspects the Format and URC fields in 
the BIND image for errors. If Format 0 is 
not specified, or if the PLU initiated the 


session limit) by sending NOTIFY(Vector Key 
X'0C') to the CP. 


The CP queues the initiation request if the 
INIT-SELF indicates that queuing is permit- 
ted, the CP supports queuing, and the DLU is 
currently umavailable. The CP queues the 
INIT-SELF request until the OLU becomes 
available. 


The URC that the ILU sends in INIT-SELF is 
returned in the CINIT. When the PLU sends 
the INIT-SELF, the URC received in CINIT 
allons the PLU to correlate the CINIT with 
the INIT-SELF. When the SLU sends the 
INIT-SELF, the PLU copies the URC from CINIT 
into BIND to allow tha SLU to correlate the 
BIND with the INIT-SELF. 


The CP returns a positive response to the 
INIT-SELF request after it verifies the 
resource availability and mode name, and, if 
applicable, it queues the initiation request. 
If an initiation failure occurs after a posi- 
tive response has been returned, the CP noti- 
fies the ILU by means of NOTIFY(Vector Key 
X'O3'). The NOTIFY includes the URC from the 
INIT-SELF in order to allow the ILU to corre- 
late the NOTIFY with the INIT-SELF. 


session and the URC is omitted from the CINIT 
request or the URC included on the CINIT 
request does not match the URC that the PLU 
sent on a previous INIT-SELF, then the PLU 
rejects the CINIT by returning a negative 
response to CINIT. 


he PLU also inspects the mode name carried 


in a control vector on CINIT. If the mode 
name does not watch the one on the corre- 
sponding INIT-SELF that the PLU sent, the PLU 
rejects the CINIT. Similarly, if the SLU or 
a third-party LU initiated the session and > 
the mode -name does not match one that is 
system-defined for tha SLU, the PLU rejects 
the CINIT. 


If the PLU finds no errors with the CINIT, it 
sends back a positive CINIT response. 


The PLU copies some CINIT parameters into the 
BINO without wmodification. These are the 
Staging indicators, the PLU Name field, and 
the SLU Name field. The URC field is copied) 
into BIND when the SLU sends the INIT-SELF, 
and the Cryptography Options field is copied 
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into BIND when both LUs support session-level 
mandatory cryptography. The mode name from 
the control vector on CINIT is copied into 
the Mode Name Structured Data Subfield of the 
User Data field of BIND. 


CINIT may include a User Data field in the 
BIND image of CINIT. If it does, the PLU 
discards the user data and does not copy the 
field into the BIND. 


When the SLU sends an INIT-SELF, the PLU Name 
field in the associated CINIT carries the 
uninterpreted name of the PLU sent in the 
INIT-SELF; otherwise, it carries the network 
name of the PLU. 


If the INIT-SELF designated the PLU as the 
DLU, the PLU copies the URC from the BIND 


image of CINIT into the BIND. Otherwise, the 


PLU omits the URC from BIND. 


If both the PLU and SLU support session-level 
mandatory cryptography and it is specified 
for the mode name sent in INIT-SELF, the 
associated CINIT carries the session 
cryptography key enciphered twice—once under 
the PLU master cryptography key and once 
under the SLU master cryptography Key; the 
former is used at the PLU, while the latter 
(carried in the BIND image) is passed by the 
PLU in BIND for use at the SLU. The session 
cryptography Key is a pseudo-random number. 
See "Chapter 6.2. Transmission Control” for 
details on cryptography. 


The PLU may modify other parameters supplied 
in the CINIT before sending them in the BIND. 
Specifically, the PLU may change the primary 
and secondary TCs' pacing window sizes and 


RSP(CINIT ) 


Flow: From PLU to CP (Normal) 


A positive response to CINIT informs the CP 
that the PLU accepts the CINIT request and 
will attempt to activate the requested LU-LU 
session with the LU named in the CINIT 
request. 


For SSCP-mediated sessions, the PLU is 
located in a subarea node. For PNCP-mediated 
sessions, the PLU is located in a peripheral 
node. 


The CINIT request includes a BIND image that 
the PLU uses in building the BIND request for 
the LU-LU session. The PLU inspects the For- 
mat and URC fields in the BIND image for 
errors. If Format 0 is not specified, or if 
the PLU initiated the session (PLU = ILU) and 
the URC is omitted from the CINIT request or 
the URC included on the CINIT request does 


the maximum RU sizes specified in CINIT. 
More details are given in the description of 
BIND in this chapter. 


The changing of any of the pacing parameters 
and maximum RU sizes on one seSSion may 
affect the performance characteristics of 
that session and of concurrently active ses- 
sions that share network resources with it. 


See the description of BIND in this chapter 
for additional rules on TS Profile and TS 
Usage modifications that are allowed. 


The route to be used for the LU-LU session is 
identified in the CINIT. For SSCP-mediated 
LU-LU sessions, CINIT carries a control vec- 
tor that contains the mode name, class of 
service, and virtual route list associated 
with the subarea path-control route to be 
used for the session. The PLU and SLU 
addresses to be used for the session flows 
are network addresses, carried in either a 
session key field or a control vector. 


For PNCP-mediated sessions, CINIT carries a 
control vector that contains the mode name 
for the LU-LU session. PNCP-mediated ses- 
sions use a direct route between peripheral 
nodes and do not use network addresses for 
the session flows. Therefore, in place of 
network addresses, CINIT carries an identifi- 
er of the adjacent link station associated 
with the node in which the SLU resides. 

CINIT can result from an INIT-SELF from one 
of the session partners (the PLU or SLU). 
Alternatively, CINIT can result from an ini- 
tiation request from a third-party LU. The 
formats and protocols for session initiation 
by a third-party LU are not described. 


not match the URC that the PLU sent on a pre- 
vious INIT-SELF, then the PLU rejects the 
CINIT by returning a negative response to 
CINIT. Otherwise, the PLU accepts the CINIT 
by returning a positive CINIT response. 


The CINIT response has an extended format 
that differs from the CINIT request. The 
CINIT response specifies control vector X'FE' 
as the only parameter of the response. 


Control vector X'FE' contains a list of con- | 
trol vector keys, received on the CINIT 
request, that the PLU does not recognize. If 
the SLU receives on the CINIT request a con- 
trol vector it does not recognize, the SLU 
includes control vector X'FE' on the CINIT 
response. Otherwise, the SLU omits control 
vector X'FE' from the CINIT response. 
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SESSION STARTED (SESSST) 


Flow: From LU to CP (Normal) 


SESSST notifies the CP that an LU-LU session 
has been successfully activated. Both the 
PLU and SLU send SESSST to their CP. The 
SESSST indicates no-response requested. 


For SSCP-mediated sessions, the PLU is 
located in a subarea node and sends SESSST to 
its SSCP. The SLU is located in either a 
subarea node or peripheral node and sends 
SESSST to either its SSCP or PNCP, respec- 
tively. 


For PNCP-mediated sessions, the PLU and SLU 
are located in peripheral nodes. Each LU 
sends SESSST to its PNCP. 


BIND FAILURE (BINDF ) 


Flow: from PLU to CP (Normal) 


BINDF informs the CP that an attempt to acti- 
vate an LU-LU session has failed, for the 
reason indicated in the BINDF. The BINDF 
indicates no-response requested. 


For SSCP-mediated sessions, the PLU is 
located in a subarea node and sends BINDF to 
its SSCP. The BINDF identifies the LU-LU 
session that failed to be activated. <A ses- 


TERMINATE-SELF (TERM-SELF )} 


Flow: From TLU to CP (Normal) 


TERM-SELF requests that the CP assist in the 
termination of a session between the sender 
of the request (the TLU) and LU named in the 
request (the DLU). The TERM-SELF indicates 
definite-response requested. 


For SSCP-mediated sessions, the TLU may be 
located in either a subarea node or peripher- 
al node. For PNCP-mediated sessions, the TLU 
is located in a peripheral node. 


The session to be terminated can be either 
queued or pending-active, from the TLU's per- 
spective. Therefore, only the ILU can send 


SESSST sent to the SSCP identifies the LU-LU 
session that is started. A session key’ con- 
taining the network addresses of the PLU and 
SLU is used for this purpose. 


The SESSST sent to the SSCP may carry addi- 
tional information by means of control vec- 
tors. Further details are not defined. 


SESSST sent to the PNCP identifies the adja- 
cent link station for the node in which the 
partner LU is located. This SESSST has an 
internal format different from the SESSST 
sent to the SSCP. 


sion key containing the network addresses of 
the PLU and SLU is used for this purpose. 
Sense data identifying the error and a reason 
code for the error are included in the BINDF. 


For PNCP-mediated sessions, the PLU is 
located in a peripheral node. The PLU does 
not send BINDF to its PNCP. 


TERM-SELF, because only the ILU is aware of 
sessions that are queued or pending-active. 
Note that from the SSCP's perspective, the 
session may be active, as well = as 
pending-active or queued. 


The LU does not send TERM-SELF to terminate 
an active LU-LU session. Instead, the LU 
sends UNBIND to the partner LU. 


The TERM-SELF request identifies the session 
to be terminated by means of the URC session 
key. The URC session key is the same as the 
one sent in the INIT-SELF that initiated the 
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session. The URC field (distinct from the 
URC session key) can be specified in 
TERM-SELF to correlate a TERM-SELF with a 
subsequent NOTIFY. 


The TERM-SELF request designates the type of 
termination to be performed, which is always 


Forced. TERM-SELF(Forced) requests the CP to 
assist’ in terminating the pending-active o- 


queued session uricondi - 


tionally. 


immediately and 


The CP .eturns a positive response once it 
kus validated the TERM-SELF request. For 


CONTROL TERMINATE (CTERM) 


Flow: From CP to PLU (Normal) 


'CTERM requests that the PLU attempt to deac- 
- tivate an LU-LU session. The CTERM indicates 


definite-response requested. 


CTERM is used to terminate an SSCP-mediated 
LU-LU session. The SSCP sends CTERM to the 
PLU, located in a subarea node, as a result 
of receiving a terminate request from an LU. 
The LU that sent the terminate request to the 
SSCP can be the PLU or SLU for the session, 
or a third-party LU. See the description of 
TERM-SELF for more details about when the PLU 
or SLU sends a termination request to the 
SSCP. Details of session termination result- 
ing from a request sent by a third-party LU 
are not defined. 


The CTERM identifies the session to be termi- - 


nated by means of a session Key containing 
the network addresses of the PLU and SLU. 
The CTERM also specifies the type of termi- 
nation requested and the reason for termi- 
nation. 


CLEAN UP SESSION (CLEANUP) 


Flow: CP to LU (Normal) | 


CLEANUP informs the LU that it is to deacti- 
vate the LU-LU session immediately, even if a 
conversation is using the session. The 
CLEANUP indicates definite response 
requested. 


CLEANUP is used to deactivate an 
SSCP-mediated LU-LU session. The SSCP sends 
CLEANUP to the LU, located in subarea node, 
as a result of receiving a terminate request 
from an LU. The LU that sent the terminate 
request to the SSCP can be the PLU or SLU for 


SSCP-mediated sessions, if an error occurs 
after a positive response has been sent, the 


“SSCP notifies the TLU by means of NOTI- 


FY(Vector Key X'03'). The NOTIFY includes 
the URC from the TERM-SELF so that the TLU 
can correlate the NOTIFY with the TERM-SELF. 


For SSCP-m-Jiated sessions, if the SSCP's 
perspective of the session is that it is 
active, the SSCP sends CTERM(Forced) to the 
PLU. See the description of CTERM in this 
chapter for more information. 


The type of termination specified in CTERM is 
either Orderly or Forced. CTERM(Orderly) 
allows the PLU to delay deactivating the ses- 
sion. In particular, the PLU does not deac- 
tivate the session while a conversation is 
using the session. CTERM(Forced) requires an 
unconditional attempt to deactivate the ses- 
sion, even if a conversation is using the 
session. 


CTERM( Forced) is the only type of termination 
that can result from a TERM-SELF sent to the 
SSCP by the PLU or SLU. Both CTERM(Orderly) 
and CTERM( Forced) can result from a termi- 
nation request sent by a third-party LU. 


CTERM is not used for PNCP-mediated sessions. 
When a PNCP-mediated session is to be termi- 
nated, the LU sends UNBIND to the partner LU. 
The PNCP does not send a terminate request to 
the LU. 


the session, or a third-party LU. See the 
description of TERM-SELF for more details 
about when the PLU or SLU sends a termination 
request to the SSCP. Details of session ter- 
mination resulting from a request sent by a 
third-party LU are not defined. 


CLEANUP can result from a TERM-SELF( Forced). 
This occurs when the SSCP is unable to proc- 
ess the TERM-SELF(Forced) and therefore must 
promote the forced termination to a cleanup 
termination. 
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The CLEANUP identifies the session to be ter- 
winated by means of a session key containing 
the network addresses of the PLU and SLU. 
The CLEANUP also specifies the the reason for 
termination. 


In response to receiving CLEANUP, the LU 
sends UNBIND with the Type set to Clean. 
UNBIND(Cleanup) deactivates the sender's 
half-session, without waiting for a response 
to the UNBSIND. 


SESSION ENDED (SESSEND) 


Flow: from LU to CP (Normal) 


SESSEND notifies the CP that an LU-LU session 
has been successfully deactivated. Both the 
PLU and SLU send SESSEND to their CP. The 
SESSEND indicates no-response requested. 


For S$SCP-mediated sessions, the PLU is 
located in a subarea node and sends SESSEND 
to its SSCP. The SLU is located in either a 
subarea node or peripheral node and sends 
SESSEND to either its SSCP or PNCP, respec- 
tively. 


For PNCP-mediated sessions, the PLU and SLU 
are located in peripheral nodes. Each LU 
sends SESSEND to its PNCP. 


UNBINO FAILURE (CUNBINOF ) 


Flow: From PLU to CP (Normal) 


UNBINDF informs the CP that an attemt of 
deactivate a session has failed, for the rea- 
son indicated in the UNBINDF. The UNBINDF 
indicates no-response requested. | 


For SSCP-mediated sessions, the PLU is 
located in a subarea node and sends UNBINOF 
to its SSCP. The UNBINDF identifies the 
LU~LU session that failed to be deactivated. 


CLEANUP is received only by an LW in a sub- 
area node. When the SLU of an S5CP-wediated 
session is located in a peripheral node, the 
SLU receives a DACTLU followed by ACTLU in 
place of CLEANUP. 


CLEANUP is not used for PNCP-mediated ses~ 
sions. When a PNCP-mediated session is to be 
terminated, the LU sends UNBIND to the part- 
ner LU. The PNCP does not send a terminate 
request to the LU. 


SESSEND sent to the SSCP identifies the LU-LU 
session that is ended. <A session key con- 
taining the network addresses of the PLU and 
SLU is used for this purpose. SESSEND also 
indicates the cause of the deactivation. 


SESSEND sent to the PNCP identifies the adja- 
“cent link station for the node in which the 
partner LU is located. This SESSEND has an 
internal format different from the SESSEND 
sent to the SSCP. 


A session key containing the network 
addresses of the PLU and SLU is used for this 
purpose. Sense data identifying the error 
and a reason code for the error are included 
in the UNBINOF. 


For PNCP~-mediated sessions, the PLU is 


located in a peripheral node. The PLU does 
not send UNBINDF to its PNCP. 
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NOTIFY 


Flow: From CP to LU and from LU to CP (Normal) 


NOTIFY is used to send information from a CP 
to an LU, or from an LU to a CP. The NOTIFY 
indicates definite-response requested. 


NOTIFY is used for SSCP-mediated sessions, 
only. An LU in either a subarea node or 
peripheral node can send or receive NOTIFY 
pertaining to an  SSCP-mediated session. 
NOTIFY is not used for PNCP-mediated ses- 
sions. 


NOTIFY carries information in the fore of a 
(vector key, vector data) pair: 


® Vector key X'03'—ILUITLU notification: 
Sent in NOTIFY from the SSCP to the ILU 
or TLU in order ta notify the LU of a 
session-initiation or -terwination fail- 
ure after a positive response has been 
returned to the INIT-SELF or TERM-SELF. 
For a session-initiation failure, the 
NOTIFY indicates a setup procedure error; 
for ai session-termination failure, it 
indicates a takedown procedure error. 
The NOTIFY also includes the reason for 
the error ard the sense data identifying 
the error. 


The URC from the INIT-SELF or TERM-SELF 
is carried in the NOTIFY ta allow the ILU 
er TLU to correlate the NOTIFY with the 
INIT-SELF or TERM-SELF. 


® Vector key X‘'O0C'-—LU-LU session-services 
capabilities: Sent in NOTIFY from an LU 
to an SSCP to convey changes in the LU's 
rye LU-LU session-services capabili- 
ties. 


The parameters of the LU-LU 
session-services capabilities include the 
LU's session count and limit, its capa- 
bility to act as a PLU or SLU, and its 
capability to support parallel sessions. 
Its capability to act as a PLU or SLU is 
indicated as: 


~-  Enabled—sessions can be started 


~  Disabled—sessions can be queued but 
not started 


-  Inhibited—sessions can be neither 
queued nor started 


Whenever an event occurs during an active 
CP-LU session causing a change in an LU's 
session-services capabilities, the LU 
sends NOTIFY to the SSCP to convey its 
new session-services capabilities. (At 
CP-LU session activation time, the LU 
conveys its sesston-services capabilities 
to the SSCP by means of control vector 
X'OC' carried in the LU's response to 
ACTLU. ) 


The session-services-capabi lities parame- 


ters determine whether a DLU is available 
for initiation of an LU-LU session. In 
terms of these parameters, a DLU is 
available for session initiation when all 
of the following conditions are met: 


- The DLU's session count is less than 
its session limit. 


- It is enabled for PLU or SLU capabil- 
ity, as requested in the INIT-SELF 
request. 


~- It supports parallel sessions with 
the OLU (this condition applies when 
one session between the OLU and DLU 
is already active). 


Otherwise, the BLU is wavailable for 
session initiation. 


The parameters spacifying the LU's ses- 
ston count and limit, and its PLU or SLU 
capability, are used to determine whether 
to queue an INIT-SELF request, as fol- 
lows : | 


- When an INIT-SELF designates a DLU 
that is currently unavail- 
able—because its session count 
equals its session limit or because 
its PLU or SLU capability as 
requested in the INIT-SELF is disa- 
bled—and the INIT-SELF specifies 
initiate/queue and the SSCP supports 
queuing of INIT-SELF, the INIT-SELF 
is queued. 


- When an INIT-SELF designates a DLU 
that is currently unavailable and 
either (1) the INIT-SELF specifies 
initiate only, (2) the SSCP does not 
support queuing of INIT-SELF, (3) the 
DLU's PLU or SLU capability as 
requested in the INIT-SELF is inhib- 
ited, or (4) the DLU does not support 
parallel sessions and aie session 
between the OLU and DLU is already 
active, the INIT-SELF request § is 
rejected (a negative response is 
returned). 


~ when the DLU sends a NOTIFY indicat- 


ing it has become available, the SSCP 
dequeues INIT-SELF requests (up to 
the session limit) for that DLU, 
resuming the session-initiation proc- 
es5. 


~ When INIT-SELF designates a DLU that 
is available (Cand other nacessary 
conditions are met), the session is 
initiated. 


The defined (vector key, vector data) pairs 
are specified in Appendix €. 
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SESSION-CONTROL RU'S 


This section describes the session-control Session control RUs pertaining to CP-LU ses- 
requests and extended responses that LNS Sion activation and deactivation are: 

sends and receives. Preceding the individual 

descriptions is a list of the RUs» grouped RU Page 
according to their use. Listed with each RU —_—_— 

is the number of the page on which the ACTIVATE LOGICAL UNIT (ACTLU) 4-17 
description of the RU begins. In addition; RSPCACTLU) 4-17 
Figure 4-3 on page 4-16 shows the RH formats DEACTIVATE LOGICAL UNIT (DACTLU) 4-19 

for the sesston-control requests and 

responses that LNS sends and receives. Session-control RUs pertaining to LU-LU ses- 


S10n activation and deactivation are: 
Each RU description includes the RU flow and 


a discussion of the function and use of the RU Page 
RU. Refer to "Appendix E. Request/Response nN ORe 

Unit (RU) Formats" for specifications of the BIND SESSION (BIND) 4-19 
RU formats. RSP( BIND ) 4-25 


UNBIND SESSION (UNBIND) 4-28 
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Session Control RU ——> 


Header Indicators | 


RH Byte 0 Bit 0 
Bits 1-2 
Bit 
Bit 
Bit 
Bit 
Bit 


RH Byte 1 Bit 
Bit 
Bit 
Bit 
Bits 4-5 
Bit 6 
Bit 7 


RH Byte 2 


RH Byte 0 Bit 0 
Bits 1-2 
Bit 
Bit 
Bit 
Bit 
Bit 


RH Byte 1 Bit 
Bit 
Bit 
Bit 
Bits 4-5 
Bit 6 


RH Byte 2 Bits 0-7 


Notes: 


reserved 


ACTLU 
DACTLU 
BIND 
UNBIND 


Expedited A 


RRI 
RU_CTGY 
reserved 


Request 
reserved 

DR2I 

ERI 

reserved 

QRI 

PI. 


BBI 
EBI 
CDI 
reserved 


< 


> 


RU_CTGY 
reserved 


Response 


reserved 
DR2I 

RTI 
reserved 


00000000 V 


1. *XX means either XX or =XX. 
2. See Appendix D for complete RH descriptions. 
3. The TH formats are not described in this book. 


Figure 4-3. 
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Session-Control RH Formats 
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ACTIVATE LOGICAL UNIT (CACTLU) 


Flow: From CP to LU (Expedited) 


ACTLU requests that the LU activate a CP-LU 
Session between itself and the CP that sent 
the ACTLU request. The CP assumes the role 
of primary NAU, while the LU assumes the role 
of secondary. The ACTLU indicates 
definite-response requested. 


The LU sends back either a positive or nega- 
tive response, depending on the parameters of 
the ACTLU request. In addition, if the for- 
mat of the ACTLU request 15 in error, or the 
LU already has a CP-LU session with the CP 
that sent the request, it sends back a nega- 
tive response. 


A description of the parameters in the ACTLU 
request follows. 


Type: This specifies the type of CP-LU ses- 
Sion activation requested. Type ERP (error 
recovery procedure) is always specified; no 
other type is defined for the ACTLU request. 
The LU sends back a negative response if the 
ACTLU request specifies a type other than 
ERP. 


Type ERP is used to activate the CP-LU ses- 
sion without affecting any active LU-LU ses- 
sions. The type of session activation that 
the LU actually performs is indicated on the 


RSPCACTLU) 


Flow: From LU to CP (Expedited) 


A positive response to ACTLU completes acti- 
vation of a CP-LU session between the LU and 
the CP that sent the ACTLU request. The 
ACTLU response also informs the CP of the 
CP-LU session capabilities and the LU-LU ses- 
sion services capabilities of the LU. 


The positive ACTLU response has an extended 
format. If the ACTLU request is acceptable 
to the LU, it sends back a positive ACTLU 
response that specifies the parameters for 
the CP-LU session and for the LU's session 
services capabilities. 


A description of the parameters in the ACTLU 
response follous. 


Type: This specifies the type of CP-LU ses- 
sion activation that the LU is performing. 
The type of session activation may be either 
Cold or ERP (error recovery procedure). 


The LU specifies type Cold when it has no 
active or pending-active LU-LU sessions. 
Otherwise, the LU specifies type ERP. 


response. The LU may perform either ERP or 
Cold session activation. 


EM Profile: This specifies the FM profile to 
be used for the CP-LU session. The FM pro- 
file indicated in the ACTLU request can be 0 
or 6. The FM profile actually used for the 
CP-LU session is indicated on the response. 


For LUs located in subarea nodes, FM profile 
6 1s always used. If the ACTLU request indi- 
cates FM profile 0, the LU negotiates it to 
6. 


For LUs located in peripheral nodes, either 
FM profile 0 or 6 may be used. If the LU 
implementation supports FM Profile 6, then 6 
is used; if the ACTLU request indicates 0, 
the LU negotiates it to 6. If the LU imple- 
mentation does not support FM profile 6, then 
FM profile 0 is used; if the ACTLU request 
indicates 6, the LU rejects the request and 
sends back a negative response. 


TS Profile: This specifies the TS profile to 
be used for the CP-LU session. TS profile l 
is the only one defined. The LU sends back a 
negative response if the ACTLU request speci- 
fies a TS profile other than 1. 


FM Profile: This specifies the FM profile to 
be used for the CP-LU session. The FM pro- 
file may be 0 or 6. For LUs located in sub- 
area nodes, FM profile 6 is always used and 
indicated in the ACTLU response. 


For LUs located in peripheral nodes, either 
FM profile 0 or 6 may be used. If the LU 
implementation supports FM Profile 6, then 6 
is used and indicated in the response. If 
the LU implementation does not support FM 
profile 6 and FM profile 0 is indicated in 
the ACTLU request, then FM profile 0 is used 
and indicated in the response. 


TS Profile: This specifies the TS profile to 
be used for the CP-LU session. TS profile 1 
is the only one defined. 


Control Vector X'00'—CP-LU Session Capabili- 


ties: This specifies the LU's capabilities 


for the CP-LU session with the CP that sent 
the ACTLU request. The CP-LU session capa- 
bilities are tnstallatior-specified for each 
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CP, and may be different for sessions with 


different CPs. The LU specifies the CP-LU 


session capabilities by means of parameters 


on the control vector. Details of the param- 
eters follow. 


e Key: This specifies the control vector 
key, X'00'. 


e Maximum RU Size: This specifies the max- 
imum RU size that either half-session may 
send. This parameter may specify a spe- 
cific maximum RU size or no maximum RU 
size. 


@ Character-Coded Capability; This speci- 


fies whether the CP is permitted to send | 


unsolicited character-coded requests to 
the LU. The capability to receive unso- 
licited character-coded requests on the 
CP-LU session is 
implementation-dependent. 


e Field-Formatted Capability: This speci- 
fies whether the CP is permitted to send 


unsolicited field-formatted requests to. 


the LU. The capability to receive unso- 
licited field-formatted requests on the 
CP-LU session is 
implementation-dependent. 


Control Vector X'0C'—LU-LU Session-Services 
Capabilities: This specifies the LU's capa- 
bilities for LU-LU sessions for which the CP 
that sent the ACTLU request will be the 


mediator. The LU session-services capabili- 


ties are installation-specified for each CP, 
and may be different for sessions with dif- 
ferent CPs. The LU specifies the LU session 
services capabilities by means of parameters 
on the control vector. Details of the param- 
eters follow. 


e Key: This specifies the control vector 
key, X'0C'. 


® Length of Vector Data: This specifies 
the length of the remainder of the con- 
trol vector. 


® Primary LU Capability: This specifies 
whether the LU is currently available as 


a PLU for LU-LU session initiation. The 


LU's current PLU capability is specified 
as enabled, disabled, or inhibited. 


— Enabled: This LU can activate ses- 
sions for which it is the PLU, pro- 
vided its LU-LU session count is less 
then its LU-LU session limit. 


- Disabled: This LU cannot activate 
sessions for which it is the PLU, but 
the CP may queue session-initiation 
requests that specify (1) this LU is 
the PLU for the session and (2) queue 
if this LU is currently unable to 
comply with the PLU/SLU speci fica- 
tion. 


- Inhibited: This LU cannot activate 
sessions for which it is the PLU, and 
the cp cannot queue 
session-initiation requests that 


specify this LU is the PLU for the 
session. | Mi 


“LUs located in sani phatal onodss are able 


to activate SSCP-mediated sessions only 
as SLUs. Therefore, these LUs always 
specify their PLU capability as inhibited 
when the CP is an SSCP. 


Secondary LU Capability: This specifies 
whether the LU is currently available as 
an SLU for LU-LU session initiation. The 
LU's current SLU capability is specified 
as enabled, disabled, or inhibited. 


- Enabled: This LU can activate ses- 
sions for which it is the SLU, pro- 
vided its LU-LU session count is less 
then its LU-LU session limit. 


~- Disabled: This LU cannot activate 
sessions for which it is the SLU, but 
the CP may queue session-initiation 
requests that specify (1) this LU its 
the SLU for the session and (2) queue 
if this LU is currently unable to 
comply with the PLU/SLU specifica- 
tion. | | 


- Inhibited: This LU cannot activate 
sessions for which it is the SLU, and 
the cP cannot queue 
session-initiation requests that 
specify this LU is the SLU for the 
session. 


LU-LU Session Limit: This specifies the 
LU's current session limit for initiating 
sessions for which the CP is_ the 
mediator. Initiation of sessions for 
which the CP is not the mediator are not 
constrained by this session limit. A 
specification of 0 means the LU has no 
session limit. 


If the LU is ina peripheral node and the 
CP is an SSCP, the LU always specifies 
its session limit as 1. | 


LU-LU Session Count: This specifies the 
LU's current session count of active ses- 
sions. for which the CP is the mediator. 


Active sessions for which the CP is not 


the mediator are not included in this 


session count. 


If the session limit is not 0 and it is 
greater than the session count, the LU is 
available for LU-LU session initiation. 


If the session limit is not 0 and it 


equals the session count, the LU is una- 
vailable for LU-LU session initiation and 
the CP may queue’ session-initiation 
requests that specify queue if the ses- 
sion limit is exceeded. 


Parallel-Session Ca abilit : This speci- 


fies the LU's capability to support 


parallel-session protocols for sessions 
for which the CP is the mediator. If the 


LU is in a peripheral node and the CP is 
an SSCP, the LU always specifies parallel 


sessions are not supported. 
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e 6SESSST Capability: This specifies wheth- 
er the LU, as an SLU, will send a SESSST 
request to an SSCP. If the LU is in a 
peripheral node, the LU always spaci fies 


DEACTIVATE LOGICAL UNIT (DACTLU) 


Flow: From CP to LU (Expedited) 


DACTLU requests the LU to deactivate the 
CP-LU session between itself and the CP that 
sent the DACTLU request. The DACTLU indi- 
cates definite-response requested. 


The LU sends back either a positive or nega- 
tive response, depending on the parameters of 
the DACTLU request. If the format of the 
DACTLU request is in error, or the type 
parameter specifies a type other than normal 
er SON, the LU sends back a negative 
response. Otherwise, the LU sends back a 
positive response, even if it has no CP-LU 
half-session to which it can correlate the 
DACTLU request. 


A description of the parameters in the DACTLU 
request follows. 


Type: This specifies the type of CP-LU ses- 
sion deactivation requested. The type of 
deactivation is either normal or session out- 
age notification (SON). 


BIND SESSION (BIND) 


Flow: From PLU to SLU (Expedited) 


BIND is sent from a PLU to an SLU to activate 
@ session between the LUs. The BINO indi- 
cates definite-response requested. 


The BIND request carries the PLU's suggested 
parameters for the session. The specifica- 
tions of the BIND parameters are based on the 
PLU's implementation-dependent support, on 
the installation-specified values currently 
in effect for the parameters, or on the CINIT 
request for the session, depending on the 
particular parameter. 


The SLU uses the BIND parameters to help 
determine whether it will send back a posi- 
tive or negative response to BIND. In addi- 
tion, if the format of the BIND request is in 
error, the SLU sends back a negative 
response. Control information in either LU 
is updated only when a positive response is 
returned. A successful BIND causes a 
half-session to be created at both PLU and 
SLU. 


it will not send SESSST. If the LU is in 
a subarea node, the LU always specifies 
it will send SESSST. 


e Normal: This specifies that the LU is to 
deactivate the CP-LU session and reset 
its half-sessions for all of the LU-LU 
sessions for which the CP is the 
wediator. 


ion- tion; This speci- 
fies that the LU is to deactivate the 
CP-LU session but not reset its LU-LU 
hal f-sessions. The DACTLU)—s_ request 
includes a specification of the cause of 
the SON deactivation. See "Session Out- 
age and Session Reinitiation' on page 4-4 
for more information on SON. See the 
definition of the DACTLU request in 
Appendix E for a List of the cause codes 
and a description of the causes. 


Receipt of DACTLU does not cause the LU to 
terminate any LU-LU sessions. 


If the LU receives a BIND request after send- 
ing a BIND request, and either (1) parallel . 
sessions betveen the two LUs are not sup~- 
ported, or (2) the current number of active 
sessions within the mode-name group is 1 less 
than the session limit for that group, then a 
BIND race has occurred. The BIND race is 
resolved in one of the following ways, with 
one LU being the winner of the race Cits BIND 
is accepted) and the other being the loser 
(its BIND is rejected): 


® If the Fully Qualified PLU Network Name 
subfield of the user data is omitted from 
both BINDs, the winner of the race is the 
LU) that sent BIND with the OAF'-DAF' 
Assignor indicator (ODAI) set to 1. The 
ODAI is carried in byte 6, bit 6 of the 
transmission header (TH) of BIND. The 
ODAI and TH are not further described in 
this book. 
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® If the Fully Qualified PLU Network Name 
subfield is present in only one of the 
BINOs, the winner is the LU that sent the 
BIND containing the subfield. 


© If the Fully Qualified PLU Network Name 
subfield is present in both BINDs, the 
winner is determined by comparing the 
fully qualified PLU network names in the 
BINDs. Fully qualified PLU network names 
are unique throughout a network; there- 
fore, one will always compare greater 
than the other in the EBCDIC collating 
sequence of the two names. The LU that 
sent the BIND containing the greater of 
the two fully qualified PLU network names 
is the wirmer. 


The comparison is made by comparing the 
two names as EBCDIC character strings, 
left-justified, and filled on the right 
with space characters, if necessary. 
Fully q:ialified LU network names contain 
no leading or embedded space characters. 


The LU that is the winner of the BIND race 
sends back a negative response to the BIND it 
received. The other LU sends back a positive 
response, umless the BIND is not acceptable 
for other reasons, such as invalid format. 


The BIND request and its response do not have 
an ERP type, in contrast to other 
session-activation requests and their 
responses, such as ACTLU. The distinction 
between simple activation and resynchronizing 
reactivation following a failure is made 
after the session has been activated. In 


some cases, change-number-of~-sessions proto- 


cols are used; in others, end-user protocols 
are invoked. 


The SLU does not reject the BIND because of 
any incompatibility it may have with the BIND 
parameters. Rather, if the BIND request is 
otherwise acceptable (for example, there are 
no format errors and the session limit is not 
exceeded), the SLU returns a positive 
response with an extended format that carries 
the complete set of session parameters. The 
specifications for the parameters can match 
those sent in the BIND request, or they can 
differ, where the SLU chooses different 
options. The parameters for which the SLU 
may choose different options are referred to 
as negotiable parameters. 


The PLU receives the positive BIND response 
and checks the parameter specifications. If 
they are acceptable, then these specifica- 
tions are used for the activated session. 
Otherwise, the PLU serds UNBIND. 


A description of the parameters in the BIND 
request follows. 


Format: This speci fies the format of the 
BIND request. Only one format is defined: 
Format 0. 


Type: This specifies the type of BINO 
request. The type is always specified as 
negotiable. The positive response to BIND 
has the same general format as the BIND 


requast. The negotiable type of BIND request 
permits the SLU to return a positive response 
in which the negotiable parameters way differ 
from those in the request. 


FM : This specifies the FM profile to 
be used for the LU-LU session. FM profile 19 
is the only one defined for LU 6.2. The FM 
profile is supplemented by the FM usage 
parameters of the BIND request. 


TS Pr: : This specifies the TS profile to 
be used for the LU-LU session. TS profile 7 
is the only one defined for LU 6.2. The TS 
profile is supplemented by the TS usage 
parameters of the BIND request. 


FM Usage (PLU)—Chaining Use; This specifies 
the PLU's use of chains that it sends to the 
SLU. Multiple-RU chains is the only use 
defined for LU 6.2. Chains may consist of 
one or more RUs. The maximua-size RU that 
the PLU sends and the verbs that the trans- 
action prograw issues to the PLU determine 
the number of RUs that make up the chain. 


FM Usage = Control Mode: This 
specifies the PLU's protocol for sending 
chains. Immediate-request mode is the only 
protocol defined for LU 6.2. The PLU waits 
for a response to a definite-response chain 
before it sends another chain. | 


FM Usage (PLUJ—Chain Response Protocol: 

This specifies the PLU's protocol for 
requesting responses to chains. Befinite- or 
exception-response requested is the only pro- 
tocol defined. A chain indicating 
definite-response requested requires a 
response from the SLU; the response may be 
positive or negative. A chain indicating 
exception-response requested requires a 
response from the SLU only when the response 
is negatives a positive response is not 
returned. 


FY Usage (PLU)—Send End Bracket: This spec- 
ifies that the PLU does not send EB chains. 


FM Usage {SLU)—Chaining Use: This specifies 
the SLU's use of chains that it sends to the 
PLU. Multiple-RU chains is the only use 
defined for LU 6.2. Chains may consist of 
one or more RUs. The maximum-size RU that 
the SLU sends and the verbs that the trans- 
action programs issues to the SLU determine 
the number of RUs that make up the chain. 


FM Usace (SLU)—Request Control Node: = This 
specifies the SLU's protocol for sending 
chains. Immediate-request mode is the only 
protocol] defined for LU 6.2. The SLU waits 
for a response to a definite-response chain 
before it sends another chain. 


FM Usade (SLU)-——Chain Response Protocol: 

This specifies the SLU's protocol for 
requesting responses to chains. Definite- or 
exception-response requested is the only pro- 
tocol defined. A - chain indicating 
definite-response requested requires a 
response from the PLU; the response may be 
positive or negative. <A chain indicating 
exception-response requested requires a 
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response from the PLU only when the response 
is negative; a positive response is not 
returned. 


FM Usage = End Bracket: This spec- 
ifies that the SLU does not send EB chains. 


FN Usage (Common)—Session Seqmenting: This 
specifies whether the PLU supports receiving 
segmented BIUs on the session. Support for 
session-level segmenting of BIUs is 
implenentation-dependent. When both the PLU 
and SLU specify in the BIND request and BIND 
response, respectively, that they support 
session segmenting, then RUs can be segmented 
on the session; otherwise, segmenting of RUs 
will not occur. Session segmenting affects 
the specifications of the maximum-size RUs 
sent by the PLU and SLU. For more details, 
see the descriptions of the TS usage parame- 
ters, Maximuw-Size RU Sent by PLU and 
Maximua-Size RU Sent by SLU. 


EN Usage (Compon)-—-FM Header Vsaqe: This 
specifies that FM headers are used on the 
session. 


EM Usage (Common)—Bracket Usage and Reset 
State: This specifies that brackets are used 
on the session and that the bracket reset 
state for the session is in-bracket (INB); 
that is, the session is in the in-bracket 
state following successful activation. 


This specifies that rule 1, conditional ter- 
mination, will be used on the session. The 
sender of the end-bracket (CEB) chain deter- 
wines whether the bracket is to end condi- 
tionally or unconditionally. If conditional, 
the receiver is allowed to reject the 
end-bracket chain and thereby keep the ses- 
sion in the in-bracket state. 


FM Usage (Common)-——BIND Response Queuing: 
This specifies whether the SLU is permitted 
to queue (hold) the BIND response for an 
indefinite period. Whether the PLU permits 
the SLU to queue the BIND response is 
imlementation-dependent. If the PLU does, 
then the permission is installation-speci fied 
for each partner SLU. All sessions with the 
same SLU have the same specification for this 
parameter; honever, the specification may 
differ for different SLUs. 


FH Usage (Comnon)—Normal-Flow Send/Receive 
Mode: This specifies that the send/receive 
protocol for FMD requests on the normal flow 
is half-chplex flip-flop. 


hd bd Ld 
d 


EM Usage (Common )-——-Recovery Responsibility: 
This specifies the responsibility for recov- 
ery from an error within the session. Syn- 
wetric recovery is the only value defined for 
LU 6.2. The sender of a negative response is 
responsible for recovery, regardless of 
whether the sender is the PLU or SLU. 


EM Usage (Common)—Contention Winner/Loser: 

This specifies whether the PLU or SLU will be 
the contention winner for the session. The 
contention winner is the brackets first 
speaker, and the contention loser is the bid- 


der. The specification of contention nwimer | 
or loser depends on whether the session is a 
parallel or single session, as indicated by 
the PS usage parameter, Parallel Session Sup- 
port, in the BIND request. 


For a parallel session, the PLU specifies 
that it is the contention winner if, for the 
wode name, the number of active sessions for 
which the PLU is the contention winner is 
less than its maxiaums otherwise, the PLU 
specifies the SLU as the contention winner. 
The PLU's maximus number of contention-winner 
sessions is determined from the = last 
change-nusaber-of-sessions protocol executed 
by the two LUs. 


For a single session, the PLU specifies that 
it is the contention winmer if, for the mode 
name, the SLU is to be the contention loser} 
otherwise, the PLU specifies the SLU as the 
contention winner. For each mode name asso- 
ciated with a single-session, the contention 
winner (PLU or SLU) for the session § is 
installation-speci fied. 

FM Usage (Common)-—-Half-Duplex Flip-Flop 
Reset : This specifies the hal f-duplex 
flip-flop reset states for the PLU and SLU 
following successful activation of the ses- 
sion. The reset states are send for the PLU 
and receive for the SLU; that is, the PLU 
sends first. 


IS Usage-—-Staging for Secondary T€ to Primary 
Te: This specifies whether pacing of 
normal-flow requests from the SLU to the PLU 
occurs in one stage or more than one stage. 
The specification is taken from the CINIT 
request for the session. See "Chapter 6.2. 
Transmission Control" for details on 
session-level pacing. 


IS Usage-—Secondary JC's Send Window Size: 
This specifies whether pacing of normal-flow 
requests sent by the SLU will occur. If 
one-stage pacing from the SLU to the PLU is 
specified for the session, this specification 
is the same as. that for the primary TC's 
receive window size. Otherwise, this spec- 
ification is taken from the CINIT request for 
the session. 


This specifies whether pacing of normal-flow 
requests received by the SLU will occur. The 
specification is taken from the CINIT request 
for the session. 


TS Usage—Maxjmum-Size RU Sent by SLU: This 
specifies the maximum-size RU that the SLU 
may send to the PLU on the normal flow. The 
PLU sets this value to the maximum size it 
allows for received RUs. All implementations 
permit the specification of a maximum-size RU 
of 256. 


The specification of the maximuam-size RU is 
between a lower bound and an upper bound, 
which are installation-specified. The lower 
and upper bounds can range between 8 and 
491420, with the lower bound less than or 
equal to the upper bound. The particular 
values allowed for the lower bound and upper 
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bound is 


implementation-dependent, except 
that winimee lower bound is less than or 
equal to 256 and the maximum upper bound is 
greater than or equal to 256. 


If session segmenting can occur for the ses- 
SiON, the upper bound used is the 
installation-specified value. Otherwise, the 
upper bound used is the minimum of (1) path 
control's maximum-size RU for the PLU node 
and (2) the installation-specified value. 
The lower bound used is always the 
installation-specified value. 


Based on the lower and upper bounds and on 
the CINIT for the session, the PLU sets the 
value for the maximum-size RU sent by SLU as 
follows: 


® If the value specified in CINIT is 
between the lower and upper bounds, the 
PLU copies the value from CINIT into 
BIND. 


e If the value specified in CINIT is less 
than the lower bound, the PLU sets the 
value in BIND to the lower bound. 


® If the value specified in CINIT is great- 
er than the upper bound, or the value in 
CINIT is not specified, the PLU sets the 
value in BIND to the upper bound. 


IS Usage-—Maximan-Size RU Sent by PLU; This 
specifies the maximum-size RU that the PLU 
may send to the SLU on the normal flow. The 
PLU sets this value to the maximunm-size RU it 
can send. The algorithm used for determining 
the maximam-size RU sent by the PLU is the 
same as that used for determining the 
waximum-Size RU sent by the SLU. 


IS Usage--Staging for Primary IC to Secondary 
Te: This specifies whether pacing of 
normal-flow requests from the PLU to the SLU 
eccurs in one stage or more than one stage. 
The specification is taken from the CINIT 
request for the session. 


IS Usage--Primary TC's Send Window Size: 

This specifies whether pacing of normal-flos 
requests sent by the PLU will occur. If 
one-stage pacing from the PLU to the SLU is 
specified for the session, this specification 
is the same as that for the secondary TC's 
receive window size. Othernise, this spec- 
ification is taken from the CINIT request for 
the session. 


IS Usage-—Primary IC's Receive Window Size: 
This specifies whether pacing of normal-flow 
requests received by the PLU will occur. The 
specification is based on the CINIT request 
for the session and an installation-speci fied 
value, as follows: 


® If the CINIT for the session specifies a 
primary TC's receive window size of 0, 
this specification is taken from the 
installation-speci fied value. 


¢ If CINIT specifies a window size other 
than 0 and the installation-speci fied 


PS Type-6 
the level of LU type-6. 


value is 0, this specification is taken 
from CINIT. 


® If CINIT specifies a window size other 
than 0 and the = installation-speci fied 
value is also other than 0, this specifi- 
cation is taken from the minimum of the 
value in CINIT and the 
installation-specified value. 


A window size of 0 means the PLU will receive 
RUs unpaced. 


PS Profile—PS Usage Format: This specifies 
the PS usage format. The Basic format is the 
only PS usage format defined. 


PS Profile-—LU Type: 
as the LU type. 


This specifies type-6 


Usage-——LU -6 Level: This specifies 
Level 2 is the LU 
type-6 level defined for LU 6.2. 


PS Usage-—-Security Manager Receive Function: 
This specifies whether the PLU supports a 
security manager for receiving a user-ID, 
password or already-verified indication, and 
profile-ID on FMH-5 Attach commands from the 
SLU. 


PS Usage—Already Veri ndicator Accept- 
ance: This specifies whether the PLU will 
accept the User-ID Already Verified indi- 
cation on FMH-5 Attach commands from the SLU. 


Usage-—Synchronization Level: This speci- 
fies the level of synchronization support for 
the session. One of two lavels of support 
may be speci fied: 


1. Confirm 
2. Confirm, Sync point, and Backout 


The level of support specified for the ses- 
sion determines the synchronization levels 
that can be specified for a conversation 
allocated to the session. The synchroniza- 
tion level, "None" (not listed), can be spec- 
ified for a conversation allocated to any 
session; therefore, "None" is not explicitly 
specified for the session. 


All LU implementations support the Confirm 
level; support for Sync point and Backout is 
implementation-dependent. If the PLU imple~ 
mentation supports Syne point and Backout, 
the specification of support-level 1 versus 
support-level 2 is installation-specified for 
each mode name. All sessions with the same 
mode name have the same specification for 
this parameter; however, the specification 
may differ for different mode names. See 
"Chapter 5.3. Presentation Services--Syne 
Point Services Verbs" for details about Sync 
point and Backout. 


PS Usage-—Responsibility for Session Reiniti- 
ation: This specifies the responsibility for 
reinitiation of a session following a session 
outage. This parameter applies only to ses- 
sions for which parallel sessions and change 
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number of sessions (CNOS) are not supported. 
Four levels of responsibility are defined: 


1. Operator controlled. 

2. Primary half-session will reinitiate. 
3. Secondary half-session will reinitiate. 
4. Either half-session may reinitiate. 


Operator controlled reinitiation means nei- 
ther LU will automatically attempt to reini- 
tiate the session. The particular level of 
responsibility for reinitiation of the ses- 
siom-—operator controlled or otherwise—can 
implementati on-dependent or 
installation-speci fied. 


Other events may cause a session to be acti- 
vated, independent of the = reinitiation 
responsibility. For example, if the 
resources manager has queued a request for 
allocation of a conversation, the resources 
manager will request activation of a session 
when LNS informs the resources manager that 
the current session has been deactivated. 


PS Usage—Parallel-Session Support: This 
specifies whether parallel sessions are sup- 
ported between the PLU and SLU. Support for 
parallel sessions is 
implementation-dependent. If the PLU imple- 
mentation supports it, the indication of sup- 
port versus no support iS 
installation-specified for each partner SLU. 
All sessions with the same SLU have the same 
specification for this parameter; however, 
the specification may differ for different 
SLUs. 


This Toeci ties ather the PLU and SLU sup- 
port the change-number-of-sessions (CNOS) 
protocols, which includes exchange of the 
Change Number Of Sessions GDS variable. Sup- 
port for CNOS is inplementation-dependent; 
however, if parallel sessions are supported, 
CNOS is also supported. If the PLU implemen- 
tation supports CNOS, then the indication of 
support versus no support is 
installation-specified for each partner SLU. 
All sessions with the same SLU have the same 
specification for this parameter; however, 
the specification way differ for different 
SLUs. 


ra Options; This specifies whether 
session-level mandatory cryptography is sup- 
ported for the session, and, if so, the 
cryptography options to be used. Support for 
session-level mandatory cryptography is 
implementation-dependent. If the PLU -imple- 
mentation supports it, the indication of sup- 
port versus no support is 
installation-specified for each mode name for 
the session, and also depends on whether the 
CINIT for the session specified session-level 
mandatory cryptography. If both the mode 
name and the CINIT for the session indicate 
support for session-level mandatory 
cryptography, then the PLU specifies in BIND 
that it is supported: otherwise, the PLU 
specifies it is not supported. All sessions 
with the same wmode name have the same spec- 
ification for this parameter; however, the 
specification may differ for different SLUs. 


The cryptography options include a length 
parameter. The PLU indicates that 
session-level cryptography is not to be used 
for the session by specifying 6 for the 
length of the cryptography options. 
Session-level mandatory cryptography is the 
only session-level cryptography defined. See 
"Sessions with Cryptography" in "Chapter 6.2. 
Transmission Control" for additional informa- 
tion. 


Primary LU Name: This specifies the name of 
the PLU for the session. The PLU name is 
always specified for an SSCP-mediated ses- 
sion. Whether it is specified for a 
PNCP-medi ated session is 
implementation-dependent. The PLU omits the 
PLU name by specifying 0 for the length of 
the PLU name (applicable only to 
PNCP-mediated sessions). 


The PLU name is taken from the CINIT for the 
session. When the SLU initiates the session, 
the PLU name is the uninterpreted name from 
the INIT-SELF. When the PLU or a third-party 
LU initiates the session, the PLU name is the 
network PLU nama derived by the CP. 


This parameter is not used by LNS. Instead, 
LNS uses the fully-qualified PLU network nama 
carried in the user data to identify the PLU 
to the SLU. 


User Data: This specifies, in a structured 
format, further parameters for the session. 
LNS makes use of the user data in the BIND 
request and response, only; LNS does not 
supply or examine the user data in the 
session-services RUs. 


Figure 4-4 shows the format of the user data 
and the preceding length. The user-data Key 
is always specified as X'00', which indicates 
structured subfields follow. 


oer User Data 


‘ 
rh 

Subfield 1] eee ISubfield n 
7 


Figure 4-4. Format of User Data 


Each subfield includes a length and is iden- 
tified by a subfield number following the 
length. When more than one subfield are 
included, they appear in ascending order by 
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The structured subfields that the PLU sends 
in BIND are: 


Number Nawe 

X'00' Unformatted Data 

X'O2' Mode Name 

X'O3' Session-Instance ID 

X'04' = =Fully Qualified PLU Netmork Nane 
X'11' = Random Data 


A T2.1-node implementation that contains a 
single LU and a single link connection, that 
does not support parallel sessions and CNOS; 
does not support the synchronization level 
for Syne point and Backout, and does not sup- 
port LU-LU verification, may omit all 
user-data subfields. The PLU omits all User 
Data subfields either by specifying 0 for the 
length of the user data, or by specifying ! 
for the length and specifying user data con- 
sisting only of the user-data Key; the choice 
is implementation-dependent. 


In general, the PLU may omit one or wore sub- 
fields; see description of individual sub- 
fields for more information. If it does, the 
entire subfield, including its length, is 
omitted. 


Details of each subfield follow. 


ad | %'00'-—Unformatted Data: This 
subfield carries installation-speci fied 


data. Support for = this 
implementation-dependent. 


subfield is 


a i X'o2' Name; Mode name 
specifies the type of service required 
for the 3 session. names are 
installation-specified. The same «ode 
names are configured at both the PLU and 
SLU for all sessions between the two LUs. 
The installation-specified configuration 
for each mode name associates that mode 
name with the set of session properties 
to be used for all sessions for that mode 
name. For a given session, the PLU uses 
the mode name from CINIT for the mode 
name in the Mode Name subfield. The par- 
ticular set of session properties associ- 
ated wi th B mode nanwe is 
implementation-dependent. 


A mode name may be nulls that is, a null 
mode name is a valid mode name. When 
specifying a null mode name, the PLU may 
omit the Mode Name subfield entirely. 
Alternatively, the PLU may specify only 
the length and number for the null mode 
name, in which case the length is 1, or 
it may specify a mode name of all space 
(X'40') characters, which is equivalent 
to a null mode name. The particular fore 
that the PLU uses to represent a null 
mode name is implementation-dependent. 


A YT2.1-node implementation that contains 
@ single LU and a single link connection, 
and thet does not support parallel ses- 


% 


sions and CNOS, may omit the Mode Name 
subfield entirely. 


The guacten instance, 10 is used to 


fier: 
uniquely identi fy the session from among 
multiple sessions between the PLU and 


SLU. Using the session-instance ID, con- 
trol operators at the PLU and SLU can 
coordinate the diagnostics (traces, for 
example) or clean-up procedures for a 
specific session. The session-instance 
ID is used also during resynchronization 
of a conversation after session outage. 


The LU that is the prisary LU for a given 
session generates the seasion-instance 
Io. The first byte of the 
session-instance ID is used to differen- 
tiate the IDs generated by one LU from 
those generated by the other LU; this 
ensures uniqueness of all the IDs used 
between two LUs. The value of the first 
byte is either X'FO' or X'00', depending 
on which LU has the greater fully quali- 
fied LU network name. The IDs generated 
by the LU with the greater fully quali- 
fied LU network name have a first byte of 
X'FO'. The appropriate value (X'FO' or 
X'00') of the first byte is determined by 
the SLU and sent in the BIND response. 


The PLU specifies the session-instance I0 
when parallel sessions and CNOS are sup- 
ported, when the synchronization level 
for the session permits Syne point and 


Backout, or when the session-instance ID 
is used as part. of an 
implementation-depandent function. Oth- 
erwise, the PLU omits the 


Session-Instance Identifier subfield. 


Subfield X'04'-—Fully Qualified PLU Net- 
work Name: The fully qualified PLU net- 
work name allows the PLU to identify 
itself to the SLU. The fully ae UL 
PLU network name 
installation-spacified at both the PLU 
and SLU. 


An LU resolves BINO-race conditions by 
comparing the fully qualified PLU network 
name it sent in the BIND request nith the 
fully qualified PLU network name it 
received in a BIND request sent by the 
partner LU. BIND race conditions are 
discussed in more detail in the first 
part of this description of the BIND 
request. 


A T2.1-node implementation that contains 
a single LU and a single link comection, 
that does not support parallel sessions 
and CNOS, that does not support the syn- 
chronization level for Syne point and 
Backout, and that does not support LU-LU 
verification, may have no fully qualified 
PLU network name. In this case, the PLU 
owits the Fully Qualified PLU Network 
Name subfield from the BIND request. 


Subfield yiom Data: This sub- 
field is cued en LU-LU verification is 
active. See "LU-LU Verification Data" on 


e Manual for LU Type 6.2 


page 4-5 for more information on the 
function of random data. 


User Request Correlation: This specifies the 
user request correlation (URC) value for the 
session when the SLU initiates the session 
(SLU = ILU). The SLU uses the URC to corre- 
late the BIND with the INIT-SELF it sent. 
When the SLU does not initiate the session, 
the PLU omits the URC from BIND. The PLU 
omits the URC by specifying 0 for the length 
of the URC. 


Secondary LU Name: This specifies the SLU 
name used to route the BIND to the intended 
SLU for the session. For PNCP-wediated ses- 


RSP( BIND) 


Flow: From SLU to PLU (Expedited) 


A positive response to BIND is sent from an 
SLU to a PLU to complete activation of a ses- 
sion between the LUs. The positive BIND 
response has an extended format that is the 
same as the BIND request. 


When the SLU receives a BIND request that is 
acceptable (for example, there are no format 
errors and the SLU's session limit is not 
exceeded), the SLU sends back a positive BIND 
response containing the complete set of ses- 
sion parameters. The specifications for the 
parameters can match those received in the 
BIND request, or they can differ, where the 
SLU chooses different options. The parame- 
ters for which the SLU may choose different 
options are referred to as negotiable parame- 
ters. 


The specifications for the matching parame- 
ters are taken directly from the BIND 
request. The specifications for the negoti- 
able parameters are determined by the SLU, 
based on its implementation-dependent sup- 
pert, on the installation-specified values 
currently in effect for the parameters, or on 
the BIND request, depending on the particular 
parameter. 


The following description of the 
BIND-response parameters indicates the spec- 
ifications that are used for the session and, 
where applicable, how they are determined. 
See the description of the corresponding 
parameters in the BIND request for details of 
the function and use of the parameters. 


Format: The SLU specifies format 0. 
Ivpe: The SLU specifies negotiable. 
FM Profile: The SLU specifies FM profile 19. 
IS Profile: The SLU specifies TS profile 7. 


i FM Usage 
} Always set to 0. 


sions, the PU uses the SLU name to route the 
BIND to the appropriate LU in its node. For 
SSCP-mediated sessions, the PU uses the des- 
tination address in the TH, instead of the 
SLU name, to route the BIND request to the 
appropriate LU in its node. 


A T2.1l-node implementation that contains a 
single LU and a single link connection, that 
does not support parallel sessions and CNOS, 
and that is connected over the single link to 
another T2.1-node implementation containing a 
single LU and single link connection, may 
omit the SLU name. The PLU omits the SLU 
name by specifying 0 for the length of the 
SLU name. 


EM Usage (PLU)—Chaining Use: The SLU speci- 
fies wultiple-RU chains. 


Usage (PLU)—Request Contro] Mode: The 
SLU specifies immediata-request mode. 
FM Usage | Response Protocol: The 


SLU specifies definite- or exception-response 
requested. 


FM Usage (PLU)——Send End Bracket: The SLU 


specifies EB is not sent. 


FM Usage (StU)-—Chaining Use: The SLU speci- 


fies multiple-RU chains. 


FM Usage (SLU)—-Request Control Mode: The 
SLU specifies immediate-request mode. 


EM Usage (SLU)-—Chain Response Protocol: The 
SLU specifies definite- or exception-response 
requested. 


FM Usage (SLU)—Send End Bracket: 


specifies EB is not sent. 


FM Usage (Common)—-Session Segmenting: The 
SLU specifies whether it supports receiving 
segmented RUs on the session. 


Usage (Common)-—FM Header Usage: The SLU 


specifies FM headers are used. 


Fu Usage {Common)——Bracket Usage and Reset 
State: The SLU specifies brackets are used 
and the bracket reset state is in-bracket 
(INS). 


FM Usage (Common)—-Bracket Termination Rule: 
The SLU specifies rule 1, conditional termi- 
nation. 


The SLU 


ND Responge Queuing; 
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FM Usage (Common)J—Normal-Flow Send/Receive 
Mode: The SLU specifies half-duplex 
flip-flop. 


EM Usage (Common)—Recovery Responsibility: 
The SLU specifies symmetric responsibility. 


FM Usage (Common)—Contention Winner/Loser: 
This specification depends on whether the 
session 1S a parallel or single session, as 
indicated by the PS usage parameter, Parallel 
Session Support, in the BIND response. For a 
parallel session, the specification is taken 
from the BIND request—the SLU accepts, and 
does not change, the specification of the LU 
that is to be the contention winner for a 
parallel session. 


For a single session, the SLU specifies that 
it is the contention winner if, for the mode 


name » the SLU is to be the 
installation-specified contention winner; 
otherwise, the specification is taken from 


the BIND request. 


FM Usage (Common)—Half-Duplex Flip-Flop 
Reset States: The SLU specifies send for the 
PLU and receive for the SLU. 


TS Usage—Staging for Secondary TC to Primary 
TC: Taken from the BIND request. 


TS Usage—Secondary TC's Send Window Size: 
Taken from the BIND request, as follows: If 
the BIND request specifies one-stage pacing 
from the SLU to the PLU, this specification 
is taken from the primary TC's receive window 
size; otherwise, this specification is taken 
directly from the secondary TC's send window 
size. 


TS Usage—Secondary TC's Receive Window Size: 
This specification 1s based on the BIND 
request for the session and an 
installation-specified value associated with 
the mode name, as follows: 


e If the BIND request for the session spec- 
ifies a secondary TC's receive window 
size of 0, this specification is taken 
from the installation-speci fied value. 


* If BIND specifies a window size other 
than 0 and the = installation-speci fied 
value is 0, this specification is taken 


directly from BIND. 


e If BIND specifies a window size other 
than 0 and the’ = installation-speci fied 
value is also other than 0, this specifi- 


cation is taken from the minimum of the 
value in BIND and the 
installation-speci fied value. 

TS Usage—Maximum-Size RU Sent by SLU: The 


SLU specifies a value between a lower bound 
and an upper bound, as follows: 


® If the value specified in the BIND 
request 1s between the lower and upper 
bounds, the value in the BIND response is 
taken from the BIND request. 


@e If the value specified in BIND is less 
than the lower bound, the SLU sets the 
value in the BIND response to the lower 
bound. | 


® If the value specified in BIND is greater 
than the upper bound, the SLU sets th> 
value in the BIND response to the upper 
bound. 


TS Usage—Maximum-Size RU Sent by PLU: The 
SLU specifies a value between a lower bound 
and an upper bound, as described above for 
the maximum-size RU sent by the SLU. 


TS Usage—Staging for Primary CPMGR to Sec- 
ondary CPMGR: Taken from the BIND request. 


TS Usage—Primary TC's Send Window Size: 
Taken from the BIND request, as follows: If 
the BIND request specifies one-stage pacing 
from the PLU to the SLU, this specification 
is taken from the secondary TC's receive win- 
dow size; otherwise, this specification is 
taken directly from the secondary TC's send 
window size. 


TS Usage—Primary TC's Receive Window Size: 
Taken from the BIND request. 


PS Profile—PS Usage Format: 
fies basic format. 


The SLU speci- 


PS Profile—LU Type: The 


type-6. 


SLU specifies LU 


PS Usage—LU Type-6 Level: The SLU specifies 


level 2. 


PS Usage—Security Manager Receive Function: 
The SLU specifies whether it supports a secu- 
rity manager for receiving a user-ID, pass- 
word or already-verified indication, and 
profile-ID on FMH-5 Attach commands from the 
PLU. 


PS Usage—Already Verified Indicator Accept- 
ance: The SLU specifies whether it will 
accept the User-ID Already Verified indi- 
cation on FMH-5 Attach commands from the PLU. 


PS Usaqe—Synchronization Level: The SLU 
specifies the synchronization level for the 
session, as follows: 


° If a session between the SLU and PLU is 
already active for the mode name, the SLU 
specifies the same level of support as 
specified for the active session. 


® If no sessions between the SLU and PLU 
are active for the mode name and the BIND 
request specifies Confirm, Syne point, 
and Backout, the SLU specifies the 
installation-specified value associated 
with the mode name for the session. 


® If no sessions between the SLU and PLU 
are active for the mode name and the BIND 
request specifies Confirm, the SLU speci- 
fies Confirm. | | 


PS Usa 
ation: 


ge—Responsibility for Session Reiniti- 
The SLU specifies the responsibility 
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PS Uss a md Ss 
The SLU gpaci ties suppor t for the use of 


for reinitiation based on the 
installation-specified responsibility and on 
the specification in the BINO request for the 
session. This does not apply when parallel 
sessions are supported. 


The matrix in Figure 4-5 shows how the SLU 
derives the specification for the BIND 
response. The rows of the matrix give the 
installation-speci fied responsibility and the 
columns give the responsibility specified in 
the BIND request. The cells of the matrix 
give the responsibility that the SLU speci- 
fies for the BIND response. 


Rows indicate installation-speci fied 
responsibility. 


Columns indicate responsibility 
received in BIND request. 


™ Cells indicate responsibility 
sent in BIND response. 


Oper- [| Oper- [| Oper~ [| Oper- 
ator ator | ator ator 
Oper- | Pri- Either} Pri- 
ator mary mary 


Primary 


Secondary] Oper- | Either 
ator 


Oper- | Pri- 
ator mary 


Figure 4-5. 


Reinitiation Responsibility 


Usaqe—Parallel-Session Support: The SLU 
speci fies parallel-session support for the 
session, as follows: 


® If a session between the SLU and PLU is 
already active, the SLU specifies the 
same support as specified for the active 
session. 


® If no sessions between the SLU and PLU 
are active and the BIND request specifies 
parallel sessions are supported, the SLU 
specifies the installation-specified val- 
ue associated with the PLU. 


© If no sessions between the SLU and PLU 
are active and the BIND request specifies 
parallel sessions are not supported, the 
SLU specifies parallel sessions are not 
suppor ted. 


change-nunber-of-sessions (CNOS) protocols, 


as follows: 


e If a session between the SLU and PLU is 
already active, the SLU specifies the 
same support as specified for the active 
session. 


¢ If no sessions between the SLU and PLU 
are active and the BIND request specifies 
CNOS is supported, the SLU specifies the 
installation-specified value associated 
with the PLU. 


e If no sessions between the SLU and PLU 
are active and the BIND request specifies 
CNOS is not supported, the SLU specifies 
CNOS is not Supported. 


Cryptography Options: 
request. 


Primary LU Name; Always omitted. 


User Data: The SLU specifies further paramne- 
ters for the session, by means of the User 
Data structured subfields. If the = SLU 
receives a BIND request containing a subfield 
it does not recognize: it ignores the sub- 
field and does not send it in the BIND 
response. 


Taken from the BIND 


The User Data subfields that the SLU sends in 
the BIND response are: 


Number Nane 
X'00' Unformatted Data 
X'02' Mode Name 
X'O3' Session-Instance ID 
X'05' Fully-Qualified SLU Network Name 
xX'11' Random Data 
X'12' Enciphered Data 
A T2.1-node implementation that contains a 


single LU and a single link comection, that 
does not support parallel sessions and CNOS, 
does not support the synchronization level 
for Sync point and Backout, and does not sup- 
port LU-LU verification, may omit all User 
Data subfields. 


In general, the PLU may omit one or more sub- 
fields; see description of individual sub- 
fields for wore information. If it does, the 
entire subfield, including its length, is 
omitted. 


Details of each subfield follon. 


. , te] ‘ ‘ ° 


subfield carries 


This 
installation-speci fied 


data. Support for this subfield is 
implementation-dependent. 

e¢ §6Subfield X'02'-— Nawe; Taken from 
the BIND request. 

* Subfield x'03'—Sessi i- 


X03 '—Session 

: Taken from the BIND) request, 
except that the SLU changes the value of 
the first byte, if necessary, to make the 
session-instance ID unique. The SLU sets 
the first byte to X'FO' if the PLU's ful- 
ly qualified LU network name is greater 
than its oem. Otherwise, it sets the 
first byte to X‘'00’. 
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° 6Subfield Moca 6 Qualified SLU Net- 
work Name: The fully qualified SLU net~ 
work mame allows the SLU to confirm its 
identify to the PLU. The ones eae 
SLU network 
ins tallation-speci fied 
and PLU. 


at “both the SLU 


All T2.1-node products can receive a BIND 
request with the fully qualified PLU net- 
work name subfield omitted. If the SLU 
receives such a BIND request, it uses a 
unique default fully qualified PLU net- 


work name in order to locally identify 


the PLU. 


A T2.1-node implementation that contains 
a single LU and a single link comection, 
that does not support parallel sessions 
and CNOS, that does not support the syn- 
chronization level for Sync point and 
Backout, and that does not support LU-LU 
verification, may have no fully qualified 
SLU network name. In this case, the SLU 


UNBIND SESSION (UNBIND) 


Flow: From LU to LU (Expedited) 


UNBIND requests the partner LU to deactivate 
the LU-LU session. The UNBIND indicates 
definite-response requested. 


The LU can send an UNBIND request as a result 
of an action at the LU (one that its CP does 
not initiate), or as a result of receiving a 
CTERM or CLEANUP request from its CP. Send- 
ing UNBIND as a result of local action is the 
normal case for terminating SSCP-mediated 
sessions and the only case for terminating 
PNCP-mediated sessions. 


Sending UNBIND as a result of receiving a 
CTERM or CLEANUP request occurs when an LU 
other than one of the session partners 
requests termination of the LU-LU session, or 
when one of the session partners sends its 
SSCP a TERM-SELF request to terminate a 
pending-active or queued session and the SSCP 
for the PLU has already sent CINIT to the 
PLU. 


The LU receiving the UNBIND request can send 
back a positive or negative response to the 
UNBIND. If the response is positive, both 
LUs send their respective CPs a SESSEND 
request. If the response is negative, the 
session was S$SCP-mediated, and the PLU sent 
the UNBIND request, the PLU sends the SSCP an 
UNBINDF request. 


The LU sends back a negative response if the 
format of the UNBIND request is in error. 


omits the Fully Qualified SLU Network 
Name subfield from the BIND response. 


* $ubfield X°ll'=-Random Data: This sub- 
field is used when LU-LU verification is 
active. See "LU-LU Verification Data" on 
page 4-5 for wore information on the 
function of random data. | 

¢ Subfield xX'12'— ‘Data: When 
the priwary LU receives the RSP(BIND), it 
compares the received enciphered data 
with its copy of the enciphered data that 
it has enciphered using the same randow 
data, its copy of the LU-LU password, and 
the DES algorithm. If they are identi- 
cal, the primary LU has verified that the 
SLU has the correct LU-LU password. 

User Request ield: Taken from 

the BIND request. 


Secondary LU Name: Always omitted. 


Otherwise, the LU sends back a positive 
response, even if it has no LU-LU 
half-session to which it can correlate the 
UNBIND request. 
A description of the parameter in the UNBIND 
request follows. 


Type: This specifies the type of LU-LU ses- 
Sion deactivation requested. The LU speci- 
fies normal deactivation when it is 
deactivating the session normally, that is, 
not as a result of an error condition. In 
this case, the two LUs stop all activity on 
the session prior to deactivating it. Activ- 
ity is stopped by exchanging BIS requests. 
See "Chapter 6.1. Data Flow Control" for a 
description of the BIS request, and "Chapter 
3. LU Resources Manager" for details of its 
use, 


The other types of session deactivation are 
associated with error conditions. Some of 
these types of session deactivation are 
caused by session outage notification (SON). 
See "Session Outage and Session Reinitiation" 
on page 4-4 for more information about SON. 


One of the other types indicates a format or 
protocol error. When this type is specified, 
sense data is also included in the UNBIND 
request. The sense data identifies the rea- 
son for the format or protocol error. 
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MAINTENANCE-SERVICES RU'S 


This section describes the 
maintenance-services requests that LNS sends 
and receives. These RUs belong to the 
FM-data category of network-services RUs. 


Preceding the individual descriptions is a 
list of the RUs. Listed with each RU is the 
number of the page on which the description 
of the RU begins. In addition, Figure 4-6 on 
page 4-30 shows the RH formats for the 
maintenance-services requests and responses 
that LNS sends and receives. 


Each RU description includes the RU flow and 
a discussion of the function and use of the 


RU. Refer to Appendix E for specifications 
of the RU formats. 


The maintenance-services RUs listed below 
permit an LU to send test data on a CP-LU 
session and receive a copy of the data from 
the CP. 


RU Page 


ECHO TEST (ECHOTEST) 4-31 
REQUEST ECHO TEST (REQECHO) 4-31 
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REQECHO 


ECHOTEST 
Header Indicators 
A 
RRI 
RU_CTGY 
reserved 
RH Byte 1 Request 
reserved 
| DReI 
ERI 
reserved 
RH Byte 2 
V 
A 
Response 
RH Byte 1 0 
BIT 1 reserved | 0 
BIT 2 DReI ~DR2 
BIT 3 RTI | tRSP 
BITS 4-5 reserved 00 
BIT 6 QRI i =QR 
BIT 7 r my *PAC 
| RH Byt- <¢ BITS 0-7 00000000 V 


Notes. 

1. *XX means either XX or “XX. 

2. See Appendix D for complete RH descriptions. 
3. The TH formats are not described in this book. 


Figure 4-6. Maintenance Services RU Formats 


4-30 SNA Format. and Protocol Reference Manual for LU Type 6.2 


ECHO TEST CECHOTEST ) 


Flow: From CP to LU (Expedited) 


ECHOTEST carries test data to the LU; the 
test data is the same as that carried in the 
corresponding REQECHO request that the LU 
sent. The ECHOTEST indicates 
definite-response requested. 


The number of ECHOTESTs that the CP sends 
back to the LU is specified by the repetition 


REQUEST ECHO TEST (REQECHO) 


Flow: From LU to CP (Expedited) 


REQECHO requests that the CP return in an 
ECHOTEST request the specified test data. 
The REQECHO indicates  definite-response 
requested. 


The repetition factor in the REQECHO request 
specifies the number of times the CP is to 


factor in the REQECHO request. The LU can 
prematurely terminate the CP's sending of 
ECHOTESTs by returning a negative response. 
Support for ECHOTEST is 
implementation-dependent. 


send back ECHOTEST requests, each carrying 
the same test data as carried in the REQECHO 
request. Support for REQECHO is 
implementation-dependent. 
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LNS PROTOCOL BOUNDARTES 


4-32 


This section shows the protocol boundaries 
that LNS has with other components of the LU 
and with the PU. LNS interacts with other LU 
components and the PU by sending and receiv- 
ing records at its protocol boundaries. Fig- 
ure 4-7 on page 4-33 shows the protocol 
boundaries and lists the record names associ- 


ated with these protocol boundaries. The 
FAPL procedures and finite-state machines 
(FSMs) of this chapter describe LNS's proto- 
cols for sending and receiving these records. 
See “Appendix A. Node Data Structures" for a 
definition of the formats of these records. 
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(A) 


Resources Manager 


(B) 
(C) 
(D) 
LU Network 
Services 
(E) 
CP-LU Half-Session in LU 
(F) 
(G) 
LU-LU Half-Session 
(H) 
Records that LNS sends: Records that LNS receives: 
(A) ACTIVATE_SESSION_RSP (B) ACTIVATE_SESSION 
SESSION_ACTIVATED DEACTIVATE_SESSION 
SESSION_DEACTIVATED 
CTERM_DEACTIVATE_SESSION 
(C) BIND_RQ_SEND_RECORD (D) BIND_RQ_RCV_RECORD 
BIND_RSP_SEND_RECORD BIND_RSP_RCV_RECORD 
UNBIND_RQ_SEND_RECORD UNBIND_RQ_RCV_RECORD 
UNBIND_RSP_SEND_RECORD UNBIND_RSP_RCV_RECORD 
ACTLU_RSP_SEND_RECORD ACTLU_RQ_RCV_RECORD 
DACTLU_RSP_SEND_RECORD DACTLU_RQ_RCV_RECORD 
PC_CONNECT PC_CONNECT_RSP 
HIERARCHICAL_RESET_RSP HIERARCHICAL_RESET 
PC_HS_CONNECT SESSION_ROUTE_INOP 
PC_HS_DISCONNECT 
(E) INIT_HS (F) INIT_HS_RSP 
HS_SEND_RECORD (contains following RUs) HS_RCV_RECORD (contains following RUs) 
RQCPID! tRSP(RQCPID)? 
INIT_SELF2 +RSP( INIT_SELF )? 
TERM _SELF2 +RSP( TERM_SELF )# 
NOTIFY_0C* +RSP(NOTIFY 0C)* 
REQECHO* +RSP(REQECHO)* 
+RSP(CINIT)* CINIT? 
+RSP(CTERM)® CTERM* 
+RSP( CLEANUP )> CLEANUP® 
tRSP(NOTIFY 03)° NOTIFY_03° 
tRSP( ECHOTEST)*® ECHOTEST® 
SESSST? 
SESSSTI* 
SESSEND® 
SESSENDI® 
BINDF? 
UNBINDF* 
(G) INIT_HS (H)} INIT_HS_RSP 


ABORT_HS 


Notes: 
Sent to or received from the PNCP-LU half-session. 
Applies to both SSCP- and PNCP-mediated sessions. 
Applies only to SSCP-mediated sessions. 
4 Internal form of SESSST and SESSEND, sent to the PNCP-LU half-session. 


Figure 4-7. Records Exchanged Between LNS and Other Components 
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LNS FLOWS 


4-34 


This section shows examples of sequence flows 
that can occur between LNS and other compo- 
nents of the LU and other nodes. These 
flows, which are shown in the’ following 
sion activation and deactivation, and LU-LU 
session initiation and termination. 


Flows for an LU in a peripheral node are 
shown in Figure 4-8 on page 4-35 through Fig- 
ure 4-16 on page 4-40. Flows for an LU ina 
subarea node are shown in Figure 4-17 on page 
4-41 through Figure 4-24 on page 4-45. The 
names shown on the flows represent the 
records listed in "LNS Protocol Boundaries" 
on page 4-32. | 7 3 a 


The subject LU in the illustrations § is 
referred to as the local LU. Components of 
the local LU, with which LNS interacts, are 
shown. Except for the PNCP-LU half-session, 


pages, illustrate some examples of CP-LU ses-~ 


the components of the PNCP are not shown in 
detail. The PNCP-LU half-session is shown 
simply for clarity of the PNCP-LU session. 


‘flows within the peripheral node. 


The following legend applies to these fig- 
ures: : : 7 


—intercomponent flow 


o——o-——>o 3 =intercomponent flow with 
intermediate-component processing. 

LNS LU network services 

LU logical unit 

LU-LU HS . LU-LU half-session. 

PC path control 

PNCP peripheral node control point 

PNCP-LU.HS PNCP-LU half-session 

PU physical unit 

RM resources manager 

SSCP system services control point 

SSCP-LU HS 


SSCP-LU half-session 
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FLOWS FOR A PERIPHERAL LU 
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Figure 4-8. PNCP-LU Session Activation 
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Figure 4-9. PNCP-LU Session Deactivation 
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SSCP-LU Session Activation to an LU in a Peripheral Node 


Figure 4-10. 
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Figure 4-11. SSCP-LU Session Deactivation to an LU in a Peripheral Node 
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figure applies only to PNCP-mediated sessions. 


LU-LU Session Initiation by Local PLU in a Peripheral Node 
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Note: This figure applies only to SSCP-mediated sessions. 


Figure 4-13. LU-LU Session Initiation by Local SLU in a Peripheral Node 
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Note: This figure applies to both PNCP- and SSCP-mediated sessions. 


Figure 4-14. LU-LU Session Initiation by Remote LU to Local LU in a Peripheral Node 
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Figure 4-15. LU-LU Session Termination by Local LU in a Peripheral Node 
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Figure 4-16. LU-LU Session Termination by Remote LU to Local LU in a Peripheral Node 
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FLOWS FOR A SUBAREA LU 
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Figure 4-17. SSCP-LU Session Activation to an LU tn a Subarea Node 
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Figure 4-18. SSCP-LU Session Deactivation to an LU in a Subarea Node 
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Figure 4-19. LU-LU Session Initiation by Local PLU in a Subarea Node 
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Figure 4-20. LU-LU Session Initiation by Local SLU in a Subarea Node 
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Figure 4-21. LU-LU Session Initiation by Remote SLU to Local PLU in a Subarea Node 
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Figure 4-22. LU-'U session Initiation by Remote PLU to Local SLU in a Subarea Node 
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Figure 4-23. LU-LU Session Termination by Local LU 
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Figure 4-24. LU-LU Session Termination by Remote LU 
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INTRODUCTION TO FORMAL DESCRIPTION 


4-46 


The remaining pages of this chapter contain 
the formal description of — LNS. This 
description consists of procedures >» 
finite-state machines (FSMs), and data struc- 
tures used only by LNS. The procedures are 
divided into two sections: High-level and 
low-level. The high-level procedures are 
organized hierarchically. The highest level 
is the root procedure of the calling tree, 


named LNS (same as the overall component)... 


The LNS root procedure calls the other 
high-level procedures. | 


The low-level procedures are arranged alpha- 
bétically by name. Some are called by the 


hi gh-level procedures} the others are called 


by the low-level procedures. 


Throughout this formal description, certain 
error checks are described. The error checks 
that all implementations make are identified 
as being required. The other error checks 
described herein are optional; implementa- 
tions may make some, none, or all of these 
checks. These required and optional error 
checks are the only error checks that imple- 
mentations make. 
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HIGH-LEVEL PROCEDURES 


LNS 


FUNCTION: LU network services (LNS) is responsible for activating and deactivating ses- 
sions between this LU and another LU or a control point (CP). There is one 
LNS process per LU in the node, and it is created (destroyed) when the LU is 
created (destroyed). LNS receives records from the resources manager (RM), 
half-session (HS), and nodal NAU manager (NNM) processes. When the records 


are received, they are routed to the appropriate procedures where they are 
processed. LLNS uses process data (called LOCAL) that can be accessed by any 
procedure in the LNS process. 

INPUT: Records from RM, HS, and NNM 


OUTPUT: Received records routed to appropriate procedures in LNS 


Referenced procedures, FSMs, and data structures: 


PROCESS_RECORD_FROM_RM page 4-48 
PROCESS _RECORD_FROM_HS page 4-48 
PROCESS _RECORD_FROM_NNM page 4-50 
RM_TO_LNS_RECORD page A-31 
NNM_TO_LNS_RECORD page A-2l 
HS_TO_LNS_RECORD page A-10 
LOCAL page 4-101 
LUCB page A-l 


Set up addressability to the control blocks used by LNS. The LNS 

process data (LOCAL) is a data area that may be referenced by any procedure 
or FSM in LNS. LOCAL is referenced only within LNS. 

The LU control block (LUCB), partner-LU control block (PARTNER_LU in 
LUCB.PARTNER_LU_LIST), and mode control block (MODE in PARTNER_LU.MODE_LIST) 
are used but not created by LNS. The CP-LU control block (CPLU_CB in 
LOCAL.CPLU_LIST) and LU-LU control block (LULU_CB in LOCAL.LULU_CB_LIST) are 
created and used only by LNS. 


Do until LNS process is destroyed. 
Select based on one of the following conditions: 
When record is received from RM 
Call PROCESS_RECORD_FROM_RM(RM_TO_LNS_RECORD) (page 4-48). 
When record is received from HS 
Call PROCESS_RECORD_FROM_HS(HS_TO_LNS_RECORD) (page 4-48). 
When record is received from NNM 
Call PROCESS_RECORD_FROM_NNM(NNM_TO_LNS_RECORD) (page 4-50). 
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PROCESS_RECORD_FROM_RM 
PROCESS_RECORD_FROM_RM 
FUNCTION: Route records received from RM to appropriate procedures. 


INPUT: RM_TO_UNS_RECORD (contains a request to activate or deactivate a session) 


Referenced procedures, FSMs, and data structures: | , 
PROCESS_ACTIVATE_SESSION page 4-77 


PROCESS_DEACTIVATE_SESSION page 4-87 
RM_TO_LNS_RECORD | page A-31 
ACTIVATE_SESSION page A-31 
DEACTIVATE_SESSION page A-31 


Select based on RM_TO_LNS_RECORD type: 
When type is ACTIVATE _SESSION 
Call PROCESS_ ACTIVATE. SESSION(C ACTIVATE_SESSION) (page 4-77). 
When type is DEACTIVATE_. SESSION 
Call PROCESS _ DEACTIVATE _sESSION( DEACTIVATE SESSION) (page 4-87). 


#& 


PROCESS_RECORD_FROM_HS 


FUNCTION: Route records received from the half-session (HS) process to the appropriate | 
procedures. The HS process represents either an LU-LU or an LU-CP session. 
If the record cannot be routed, a negative response is sent or the error is 
logged. 


INPUT : HS_TO_UNS_ RECORD (usually contains a network services BIU) 


Referenced procedures, FSMs, and data structures: 


PROCESS_INIT_HS_RSP page 4-88 
PROCESS ABORT_HS a page 4-77 
PROCESS _CINIT_RQ page 4-82 
PROCESS NOTIFY _RQ page 4-89 
PROCESS_ECHOTEST_RQ page 4-87 
PROCESS _CLEANUP_RQ page 4-84 
PROCESS_ CTERM RQ page 4-85 
PROCESS_ INTT_SELF_RSP page 4-88 
PROCESS _ TERM. SELF_RSP page 4-91 
PROCESS_REQECHO_RSP page 4-90 
PROCESS _NOTIFY_RSP page 4-89 
BUILD_AND_SEND_RSP_OR_LOG | page 4-66 
LOCAL page 4-101 
HS_TO_LNS RECORD page A-10 
INIT_HS_RSP page A-11 
ABORT_ HS | page A-1] 
HS_ RCV RECORD page A-1! 
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PROCESS_RECORD_FROM_HS 
Initialize LOCAL.SENSE_CODE to X'00000000'. 


Select based on HS_TO_LNS_RECORD type: 
When type is INIT_HS_RSP (This record is received only from LU-LU half-sessions. 
INIT_HS_RSP from CP-LU half-session is explicitly received elsewhere. ) 
Call PROCESS_INIT_HS_RSPCINIT_HS_RSP) (page 4-88). 


When type is ABORT_HS (received only from LU-LU half-sessions) 
Call PROCESS_ABORT_HS(ABORT_HS) (page 4-77). 


When type is HS_RCV_RECORD (received only from CP-LU half-sessions) 
(HS_RCV_RECORD always contains an NS header ) 
Optionally check the format of the RH (see Figure 4-2 on page 4-8 for correct 
RH formats). 
If there is an RH format error then 
Call BUILD_AND_SEND_RSP_OR_LOG(HS_RCV_RECORD) (page 4-66) 
to send a negative response or log the error. 


Else 
If HS_RCV_RECORD contains a request (RH.RRI=RQ) then 
Select based on the NS header (first 3 bytes) in HS_RCV_RECORD.RU: 

When CINIT 
Call PROCESS CINIT_RQ(HS_RCV_RECORD) (page 4-82). 

When NOTIFY 
Call PROCESS_NOTIFY_RQ(HS_RCV_RECORD) (page 4-89). 

When ECHOTEST 
Call PROCESS_ECHOTEST_RQ(HS_RCV_RECORD) (page 4-87). 

When CLEANUP and this node is a subarea node 
Call PROCESS_CLEANUP_RQ(HS_RCV_RECORD) (page 4-84). 

When CTERM and this node is a subarea node 
Call PROCESS_CTERM_RQ(HS_RCV_RECORD) (page 4-85). 

Otherwise 
Set LOCAL.SENSE_CODE to X'10030000' (function not supported). 
Call BUILD_AND_SEND_RSP_OR_LOG(HS_RCV_RECORD) (page 4-66) 

to send a negative response or log the error. 


Else (HS_RCV_RECORD contains a response) 
Select based on the NS header (first 3 bytes for positive response; 3 bytes 
following sense data for negative response) in HS_RCV_RECORD.RU: 

When INIT_SELF 
Call PROCESS_INIT_SELF_RSP(HS_RCV_RECORD) (page 4-88). 

When TERM_SELF 
Call PROCESS_TERM_SELF_RSP(HS_RCV_RECORD) (page 4-91). 

When REQECHO 
Call PROCESS _REQECHO_RSP(HS_RCV_RECORD) (page 4-90). 

When NOTIFY 
Call PROCESS_NOTIFY_RSP(HS_RCV_RECORD) (page 4-89). 

Otherwise 
Optionally log the error with sense code 1003 (function not supported). 
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PROCESS_RECORD_FROM_NNM 
PROCESS_RECORD_FROM_NNM 


Route records received from the nodal NAU manager (NNM) to the appropriate 
procedures. 


NNM_TO_LNS_RECORD (usually contains a session activation or session deacti- 
vation BIU) 


Referenced procedures, FSMs, and data structures: | 


PROCESS BIND_RQ page 4-79 
PROCESS _BIND_RSP 7 page 4-81 
PROCESS_UNBINO_RQ 7 io. : page 4-91 
PROCESS_UNGINO_RSP page 4-92 
PROCESS_ACTLU_RQ , | page 4-78. 
PROCESS_DACTLU_RQ : page 4-86 
PROCESS_PC_CONNECT_RSP i | page 4-90 
PROCESS_ SESSION _ROUTE_ INOP page 4-90 
PROCESS |  HIERARCHICAL_| RESET | : page 4-87 
NNM_TO_ UNS_ RECORD | page A-2) 
BIND_RQ_RCV_RECORD page A-21 
BIND_RSP_RCV_RECORD page A-22 
UNBIND_RQ_RCV_RECORD page A-23 
UNBIND_RSP_RCV_RECORD page A-23 
ACTLU_RQ_RCV_RECORD page A-21 
DACTLU_RQ_RCV_RECORD page A-22 
PC_CONNECT_RSP | | page A-22 
SESSION_ROUTE_ INOP 7 pa | page A-~23 
HIERARCHICAL_RESET page A-22 


LOCAL page 4-101 
Set LOCAL.SENSE_CODE to X'00000000'. | 


Select based on NNM_TO_LNS_RECORD type: 
When type is BIND _RQ_RCV_ RECORD 
Call PROCESS_BINO_RQ(BIND_RQ_RCV_RECORD ) (page 4-79). 
When type is BIND _RSP_ RCV_RECORD 
Call PROCESS_ BIND _RSP(BIND_ RSP_RCV_ RECORD) (page 4-81). 
When type is UNBIND _RQ_RCV_| RECORD 
Call PROCESS_UNBIND_RQCUNBIND_RQ_RCV_ RECORD) (page 4-91). 
When type is UNBIND _RSP_ RCV_RECORD 
Call PROCESS _ UNBIND_ RSPCUNBIND _RSP_RCV RECORD) (page 4-92). 
When type is ACTLU | RQ_RCV_, RECORD 
Call PROCESS_ACTLU_RQ(ACTLU_RQ_RCV_ RECORD) (page 4-78). 
When type is DACTLU RQ_RCV_ RECORD 
Call PROCESS_DACTLU_RQ(DACTLU | R@_RCV. RECORD) (page 4-86). 
When type is PC_ CONNECT_ RSP 
Call PROCESS_PC_CONNECT_RSP( PC_CONNECT_ RSP) (page 4-90). 
When type is SESSION_ROUTE_INOP 
Call PROCESS_ SESSION _| ROUTE _INOP(SESSION_ROUTE_ INOP) (page 4-90). 
When type is HIERARCHICAL__ RESET 
Call PROCESS_ HIERARCHICAL_| RESET (HIERARCHICAL_ RESET) (page 4-87). 
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LOW-LEVEL PROCEDURES {IN ALPHABETICAL ORDER) 


ACTIVATE_SESSION_ERROR 


Perform error checking upon receipt of an activate-session request from RM. 
These error checks are required. 


TRUE if error; otherwise, FALSE. When TRUE, ERROR_TYPE is set. When FALSE, 
CP_ID is set. 


Referenced procedures, FSMs, and data structures: 


LU_MODE_SESSION_LIMIT_EXCEEDED page 4-76 
ACTIVATE_SESSION page A-31 
PARTNER_LU page A-2 
MODE page A-3 
CP_Iod page A-2 
ERROR_TYPE page 4-101 


If there is not sufficient storage available to start a new session then 
Return with a value of TRUE (ERROR_TYPE—RETRY). 


Determine the control point identifier (CP_ID) to be associated with the new 
LU-LU session. For LUs in a subarea node, the CP_ID is obtained from the 
control block associated mith the active SSCP-LU session. If the SSCP-LU 
session is not active, the CP_ID cannot be obtained. For LUs in a peripheral 
node, a "request CP identifier (RQCPID)" record is sent to the local control 
point (PNCP). The PNCP attempts to determine the control point to be used 
based on the (partner LU, modename) pair. If determined successfully and an 
active session exists between this LU and that CP, a RQCPID response record 
is returned containing the correct CP_ID. Otherwise, a negative RQCPID 
response is returned containing no CP_ID. 

If the CP_ID cannot be obtained then 

Return with a value of TRUE CERROR_ TYPE—NO_RETRY). 


Locate the PARTNER_LU and MODE contro] blocks using the partner LU and ‘wctie names 
from the passed ACTIVATE_ SESSION record. 
Call LU_MODE_SESSION_ LIMIT ~ EXCEEDED( PARTNER_LU.FULLY_QUALIFIED_LU_NAME, MODE » 
ACTIVATE_SESSION.SESSION_TYPE, ACTIVE_AND_PENDING_ACTIVE) (page 4-76). 
If the LU-LU session limit for the (partner LU, modename) pair will be 
exceeded then 
Return with a value of TRUE (ERROR_TYPE—-RETRY).— 


If the LU-LU session limit associated with the control point will be exceeded then 
(The control point has a session limit for every LU it is mediating sessions for. 
This limit indicates the maximus number of sessions this LU way have with other 
LUs.) 

Return with a value of TRUE (ERROR_TYPE—RETRY). . 


If the new LU-LU session is to be PNCP-mediated and this LU is unable to act as 
@ PLU then | 
Return with a value of TRUE (ERROR_TYPE-——-NO_RETRY). 


If this LU is unable to act as a PLU or SLU then 
Return with a value of TRUE (ERROR_TYPE—NO_RETRY). 


Return with a value of FALSE (no error found). 
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4-52 


BIND_RQ_STATE_ERROR 


Determine if there is a state error on receipt of e BIND request. Required 
checks are explicitly indicated. 


BIND_R@ RCV_RECORD 


TRUE if error; otherwise, FALSE. If TRUE, LOCAL.SENSE_CODE is set to appro- 
priate sense data. Pat 


Referenced procedures > FSMs, and data structures: | ; | 
BIND_SESSION_ LIMIT EXCEEDED page 4-55 


LOCAL | oh 4 page 4-101 
BIND RQ _ RCV_RECORD ——— page A-21 
PARTNER_LU | | page A-2 
MODE | | page A-3 
SESSION_TYPE | | page 4-101 


Note: The following checks are optional except when specifically indicated 
as required. 


If there is insufficient storage available to estatilish @ new session then 
Set LOCAL.SENSE_CODE to X'08120000' (insufficient resources ). 
Return with a value of TRUE terror}. 


If this LU is currently unable to act as an SLU then 
Set LOCAL.SENSE_CODE to X'083A0000' (LU not enabled). 
Return with a value of TRUE (error). 


Locate the PARTNER_LU control block using the user data PLU name field in BIND. 
If the levels of session security between LUs do not match then (required check) 
Set LOCAL.SENSE_CODE to X'O080F6051' (Security Violation). 
Return with a value of TRUE (error). 
Locate the MODE control block using the user data mode name field in ‘BIND. 
If either control block cannot be located then 
Set LOCAL.SENSE_CODE to X'0835xxxx' (xxxx is offsat to PLU name or mode name). 
Return with a value of TRUE (error). 


The following determines the session type for this LU so that the check for 
whether the session limit will be exceeded may be made. 
If parallel sessions are not supported with the partner LU and | 
MODE .MIN_CONWINNERS_LIMIT = 1 then 
Set SESSION_TYPE to FIRST_SPEAKER. 


Else (use value in BIND request) . 
If BIND specifies the secondary as contention winner then 
Set SESSION_TYPE to FIRST_SPEAKER. 
Else 
Set SESSION_TYPE to BIDDER. 


Call BIND _SESSION_LIMIT_EXCEEDED( PARTNER_LU.FULLY, QUALIFIED_LU_NAME, MODE, 
SESSION LTYPE> BINO _RQ_RCV_| RECORD. ADDRESS) (page 4-55). 
If the session limit will be exceeded then 
Return with a value of TRUE (LOCAL.SENSE_CODE is set by BIND_SESSION_LIMIT_EXCEEDED). 


Do consistency checks (on PS usage fields) for parallel sessions using either the 
same partner-Lu or the sawe (partner-Lu, mode name) pair (see BIND request in Appendix E). 
Yf there is a consistency error then | 
Set LOCAL.SENSE_CODE to X'O083Sxxxx' (xxxx is offset to inconsistent field). 
Return with a value of TRUE (error). 


If this LU's cryptography support capabi li ty ose not match that specified in BIND then 
(this check is required) 
Set LOCAL.SENSE_CODE to X‘O835xxxx' (xxxx is offset to cryptography field). 
Return with a value of TRUE (error). 


Do consistency checks on conversation-level security indicators 
for parallel sessions using the same partner_LU. 
If there is a consistency error then 
Set LOCAL.SENSE_CODE to X'080F6051' (Security Violation). 
Return with a value of TRUE (error). 
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If cryptography is supported with the partner LU, but the cryptography 

component (that enciphers and deciphers) is not active then (this check is required) 
Set LOCAL.SENSE_CODE to X'08480000' (cryptography function inoperative). 
Return with a value of TRUE (error). 


If a duplicate user data session instarce identifier exists then (another active session 
is using the same identifier--use SESSION_ID field in LULU_CB) 
Set LOCAL.SENSE_CODE to X'08520001' (chplicate session-activation request). 
Return with a value of TRUE (error). 


If the SLU supports sending segments, the PLU does not support receiving 
segments, and the lower bound of the maximum RU size (see the discussion 
in BIND [page 4-19]) sent for this (partner-LU, mode name) pair 
is greater than the maximum RU size for the link then 

Set LOCAL.SENSE_CODE to X'0835xxxx' Oooox is offset to segmenting field). 
Return with a value of TRUE (error). 


BIND_RSP_STATE_ERROR 


Perform state error checking on a received BIND response. Required checks are 
explicitly indicated. 


BIND_RSP_RCV_RECORD, LULU_CB 


TRUE if error; otherwise, FALSE 


Referenced procedures, FSMs, and data structures: 
BIND_RSP_RCV_RECORD page A-22 
LULU_CB : | page A-5 


Note: The following checks are done only on positive response to BIND and 
are optional except where explicitly indicated as required. 


If the BIND request specified that an alternate code set will not be used and 
the BIND response specifies that an alternate code set may be used then 
Return with a value of TRUE (error). 


Pacing and maximum RU size checks | 


If the pacing staging indicators in the BIND response are not the same as 
those specified in the BIND request then 
Return with a value of TRUE (error). 


If secondary-to-primary pacing is one-stage and the secondary send window size 
in the BIND response is not the same as that specified in the BIND request then 
Return with a value of TRUE (error). 


If the secondary receive window size in the BIND response is greater than that 
specified in the BIND request or the primary send window size is greater than 
that specified in the BIND request then (a window size of 0 is treated as 
infinitely large for these comparisons) 

Return with a value of TRUE (error). 


If the primary receive window size in the BIND response is not the same as 
that specified in the BIND request then 
Return with a value of TRUE (error). 


Determine if the secondary or primary send maximum RU sizes are within installation- 
defined bounds. If path control for the PLU does not support segmenting, then the 
secondary send maximum RU size must not exceed the maximum size allowed on the link. 

If the secondary or primary send maximum RU sizes are not within the installation- 
defined bounds then 
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Return with a value of TRUE (error). 


PS usage checks 


If there are other active sessions to this partner-LU and 
the levels of conversation security between sessions to this partner-LU 
do not match then (required check) 

Return with a value of TRUE (error). 

If there are other active sessions for this (partner-LU, mode name) pair and 
the values of the BIND response fields for synchronization level and session 
reinitiation do not equal those of the other active sessions then 

Return with a value of TRUE (consistency error). 


Else (no other sessions active for this [partner-LU, mode name] pair) 
If the BIND response specifies a synchronization level of Confirm, Sync Point, 
and Backout and the BIND request specified only Confirm then 
Return with a value of TRUE (error). 


If the BIND response specifies parallel sessions not supported then 
If the BIND response specifies session reinitiation responsibility as not 
operator controlled and the BIND request specified operator controlled then 
Return with a value of TRUE (error). 


If the BIND response specifies session reinitiation responsibility as 
secondary will reinitiate and the BIND request specified primary will 
reinitiate then 

Return with a value of TRUE (error). 


If the BIND response specifies session reinitiation responsibility as 
primary will reinitiate and the BIND request specified secondary will 
reinitiate then 

Return with a value of TRUE (error). 


If the values of the BIND response fields for parallel sessions support and 
change number of sessions support are not the same as specified in the BIND 
request then 

Return with a value of TRUE (error). 


Contention winner checks 


If the BIND response specifies parallel sessions supported then 
If the value of the BIND response contention winner field is not the 
same as that specified in the BIND request then 
Return with a value of TRUE (error). 


Else (parallel sessions not supported) 
If the BIND response contention winner is specified as the primary and the 
BIND request was specified as the secondary then 
Return with a value of TRUE (error). 


Cryptography checks (these checks are required). 


If the BIND response cryptography field values are not the same as those speci fied 
in the BIND request then 
Return with a value of TRUE (error). 


PLU name (not in user data) is ignored 


The primary LU name (the one not in the User Data field) in the BIND 
response is ignored. 
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User data subfield checks 


If LU-LU verification is active (LULU_CB.RANDOM is non-empty) then 
If enciphered data is absent or incorrect (see page 4-25) then 
Return with a value of TRUE (error). 
If the user-data mode name in the BIND response is not the same as that 
specified in the BINO request then 
Return with a value of TRUE (error). 


If the user-data session-instance identifier in the BIND response is not 


specified correctly (see page E-16) then 
Return with a value of TRUE (error). 


URC checks 


Y¥f the URC in the BIND response is not the same as that specified 
in the BIND request then 
Return with a value of TRUE (error). 


Recurn with a value of FALSE (no error). 


BINOD_SESSION_LIMIT_EXCEEDED 


Determine whether or not session limits are exceeded for a received BIND 
request. 


PARTNER_LU.FULLY_ QUALIFIED LUNAME, MODE, SESSION_TYPE (FIRST SPEAKER or BID- 
DER), ADDRESS (TH address fields from the received BIND request). 


TRUE if limits exceeded; otherwise, FALSE. If TRUE, LOCAL.SENSE_CODE is set 
to appropriate sense data. 


Referenced procedures, FSMs, and data structures: 


LU_MODE_SESSION_LIMIT_EXCEEDED page 4-76 
ADDRESS page A-34 
LOCAL page 4-101 
MODE page A~3 
PARTNER_LU page A-2 


If session limit is being negotiated and the proposed 
session limit is > than the current session Limit 
(MODE .CNOS_NEGOTIATION_IN_ PROGRESS = TRUE) then 
If active session count is 2 the proposed limit then 
Set LOCAL.SENSE_CODE to X'08050000'. 
Set RC to TRUE. 


—~ Else 
If the sum of active session count and pending session 
count is >= the proposed session limit then 
Set LOCAL.SENSE_CODE to X'08050000'. 
Set CHECK _WINNER_FLAG to TRUE. 


Else (session limits not being negotiated) 
Call LU_MODE_SESSION_LIMIT_EXCEEDED( PARTNER_LU.FULLY_QUALIFIED_LU_NAME, MODE, SESSION_TYPE, 
ACTIVE ) (page 4-76). 
If the session limit is exceeded then 
Set RC to TRUE (LOCAL.SENSE_CODE is set by LU_MODE_SESSION_LIMIT_EXCEEDED). 


Else 
Call LU_MODE_SESSION_LIMIT_EXCEEDED( PARTNER_LU. FULLY, QUALIFIED _LU_NAME ,MODE ,SESSION_TYPE, 
ACTIVE_AND_PENDING ACTIVE) (page 4-76). 
If the session liwit is exceeded then 
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CHECK_WINNER_FLAG is set to TRUE. 


| CHECK FOR BIND RACE CONDITION 


If CHECK_WINNER_FLAG then 
Determine which LU is the BIND race winner. A comparison is made between the 
SLU name and PLU name (PARTNER_LU.FULLY_QUALIFIED_LU_NAME } - 
using the EBCDIC collating sequence. 
The "greater" one is the winner. Before the comparison is made, the shorter 
name is padded with space (X'40') characters so that the lengths are equal. 
If neither LU name is Known, the result is equivalent to name equality in the 
comparison (this can occur only for LUs in peripheral nodes that do not Know 
their names). When this occurs, the winner is determined by using the ODAI 
field in the ADDRESS of the BIND request. If the ODAI value is 0, then this 
LU is the winner; otherwise, the other LU is the winner. 


If this LU is the winner then 
Set RC to TRUE. 


Else 
Reset LOCAL.SENSE_CODE to X‘'00000000'. 


Set RC to FALSE. 
Return with the value of RC. 


BUILD_AND_SEND_ACT_SESS_RSP_NEG 


FUNCTION: Build and send ACTIVATE_SESSION_RSP (negative) to RM. 


INPUT: Correlator (in  LULU_CB or ACTIVATE_SESSION) to activate-session request and 
ERROR_TYPE (indicates retry or no retry). 


OUTPUT: ACTIVATE_SESSION_RSP sent to RM 


Referenced procedures, FSMs, and data structures: 


ACTIVATE_SESSION_RSP | page A-20 
ACTIVATE_SESSION page A-31 
LULU_CB page A-5 
ERROR_TYPE page 4-101 


Create ACTIVATE_SESSION_RSP record. 

Set ACTIVATE_SESSION_RSP.CORRELATOR to passed correlator. 
Set ACTIVATE_SESSION_RSP.TYPE to NEG. 

Set ACTIVATE_SESSION_RSP.ERROR_TYPE to passed ERROR_TYPE. 


Send ACTIVATE_SESSION_RSP to RM. 
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BUILD_AND_SEND_ACT_SESS_RSP_POS 


FUNCTION: Build and send ACTIVATE_SESSION_RSP (positive) to RM. 
INPUT: LULU_CB 


OUTPUT: ACTIVATE_SESSION_RSP sent to RM 


Referenced procedures, FSMs, and data structures: 
LULU_CB page A-5 
ACTIVATE_SESSION_RSP page A-20 


Create ACTIVATE_SESSION_RSP record. 

Set ACTIVATE_SESSION_RSP.CORRELATOR to LULU_CB.CORRELATOR (enables RM to correlate 
this response with the original ACTIVATE_SESSION request). 

Set ACTIVATE_SESSION_RSP.TYPE to POS (positive). 

Set ACTIVATE_SESSION_RSP.HS_ID to LULU_CB.LU_LU.HS_ID (the identifier of the 
half-session just activated). 

Set ACTIVATE_SESSION_RSP.SESSION_INFORMATION.HALF_SESSION_TYPE to 
LULU_CB.HALF_SESSION_TYPE (primary or secondary). 

Set ACTIVATE_SESSION_RSP.SESSION_INFORMATION.BRACKET_TYPE to LULU_CB.SESSION_TYPE 
(first speaker or bidder). 

Set ACTIVATE_SESSION_RSP.SESSION_INFORMATION.RANDOM_DATA to 
LULU_CB.RANDOM (RM uses this value for LU-LU verification). 


Send ACTIVATE_SESSION_RSP to RM. 


BUILD_AND_SEND_ACTLU_RSP_NEG 


FUNCTION: Build and send a negative ACTLU response. 


INPUT: ACTLU_RQ_RCV_RECORD 


OUTPUT : ACTLU_RSP_SEND_RECORD sent to NNM 


Referenced procedures, FSMs, and data structures: 


LOCAL page 4-101 
ACTLU_RQ_RCV_RECORD page A-2] 
ACTLU_RSP_SEND_RECORD page A-17 


Create ACTLU_RSP_SEND_RECORD. 
Set ACTLU_RSP_SEND_RECORD.LU_ID to this LU's identifier. 
Copy the PC_ID, ADDRESS, EFI, SNF, and RH from the ACTLU_RQ_RCV_RECORD to 
the ACTLU_RSP_SEND_RECORD. 
Set ACTLU_RSP_SEND_RECORD.DCF to the appropriate value. 
Set ACTLU_RSP_SEND_RECORD.RH to indicate negative response (SD, NEG, and 
byte 2 of RH set to all 0's). 
Set ACTLU_RSP_SEND_RECORD.RU to the sense data (from LOCAL.SENSE_CODE) followed 
by the ACTLU request code. 


Send the ACTLU_RSP_SEND_RECORD to the CP via the nodal NAU manager. 
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BUILD_AND_SEND_ACTLU_RSP_POS 


FUNCTION: Build and send a positive ACTLU response. Also, initialize the 
hal f-session. : 


ACTLU_RQ_RCV_RECORD, INIT_HS_RSP 


CP-LU half-session initialized and ACTLU_RSP_SEND_RECORD sent to NNM 


Referenced procedures, FSMs, and data structures: 


FSM_STATUS page 4-94 
LULU_CB | page A-5 
ACTLU_RQ_RCV_RECORD page A-21 
ACTLU_RSP_SEND_RECORD | page A-17 
INIT_HS | page A-16 
INIT_HS_RSP | page A-1! 


Create ACTLU_RSP_SEND_RECORD. 

Set ACTLU_ RSP_ SENO_ RECORD. LU_ID to this LU's identifier. 

Copy the PC_ ID, ADDRESS, EFI; SNF» and RH fields from the ACTLU RARCV, RECORD 
into the ACTLU_ RSP_SEND_RECORD. 

Set ACTLU_RSP_ SEND_ RECORD.RH to indicate posi tive response (RSP, ~SD, POS, 
and RH byte 2 set to all 0's). 


The following builds the ACTLU response RU--see Appendix E description tor 
field settings not explicitly show here. 

Find all LU-LU sessions (represented by LULU_CBs ) being 

mediated by this CP (the CP_ID in ACTLU matches that in the LULU_ cB). 

If there are no active or pending active LU-LU sessions being mediated by this 

CP then 
Set ACTLU response type of activation to cold. 
Reset all LU-LU sessions being mediated by this CP by ails FSM_STATUS 
with a RESET_NORMAL input (page 4-94). 


Else 
Set ACTLU response type of activation to ERP. 


If FM profile 6 is supported by this LU then 
Set the FM profile field in the ACTLU response to 6. 


Build control vector X'00' (Appendix E). 
Build control vector X'0C’ (Appendix E). Peripheral nodes always suppress 
sending the SESSST RU; subarea nodes always send SESSST. The LU-LU session 
count is determined by coumting all the LULU_CBs associated with (being 
wediated by) this CP. For peripheral node sessions with an SSCP (as opposed : 
to a PNCP) the primary LU capability is inhibited (not able ever to be a primary), 
the LU-LU session limit is 1, and parallel session capability is not supported. 
Put the control vectors in the ACTLU response RU. 
(End of building ACTLU response RU.) 


Create the new CP-LU half-session process. 

Create an INIT_HS record to be sent to the CP-LU half-session. 

Set INIT_HS. PC_ ID to ACTLU_RQ_RCV_RECORD.PC_ID. 

Set INIT_HS.TYPE to secondary (LU is always ~ secondary with respect to CP}. 

Set INIT_HS.DATA_TYPE to indicate this record contains an ACTLU_IMAGE. 

Set INIT_ _HS. ACTLU_ IMAGE.FM_PROFILE and TS_PROFILE to the corresponding field values 
from the ACTLU response RU. 

Set INIT_HS.ACTLU_IMAGE .MAX_RU_SIZE to the maximum RU size allowed on this session 
(implementation-defined). 


Send the ACTLU_RSP_SEND_RECORD to the CP via the nodal NAU manager (NNM). 

Send the INIT_HS record to the CP-LU half-session. 

Receive the INIT_HS_RSP from the CP-LU half-session (this response is always positive). 
This response is used just so CP-LU and LU-LU half-sessions operate in the same 
manner. 
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BUILD_AND_SEND_BINO_RQ 


FUNCTION: Build and send a BIND request. 
INPUT: LULU_CB 
OUTPUT: BIND_RQ_ SEND_RECORD sent to NNM 


Referenced procedures, FSMs, and data structures: 


LULU_CB page A-5 
BIND_RQ_SEND_RECORD page A-17 
LUCB page A-] 


Create BIND_RQ_SEND_RECORD to contain the BIND request. 

Set BIND _RQ SEND_RECORD.LU_ID to this LU's identifier. 

Set BIND_RQ_SEND_RECORD.PC_ID to LULU_CB.LU_LU.PC_ID Cidentifies the path control 
that the BIND will flow through). 

Set BIND_RQ_SEND_RECORD.ADDRESS to LULU_CB.LU_LU.ADDRESS (TH addresses). 

Set BIND_RQ_SEND_RECORD.EFI to EXP (expedited). 

Set BIND_RQ_SEND_RECORD.SNF to a unique identifier. This identifier is 

also saved in LULU_CB.SENT_BIND_RQ.SNF for correlating the BIND response later. 

Set BIND_RQ_SEND_RECORD.RH to the appropriage values (Figure 4-3 on page 4-16). 

Set BIND_RQ_SEND_RECORD.RU to the appropriate values (see page 4-19). 

Insert the random data found in the BIND_RQ_SEND_RECORD.RU into the 
LUCB.PENDING_RANDOM_DATA_LIST. 

Set BIND_RQ_SEND_RECORD.DCF to the appropriate value. 

Save the BIND request in the LULU_CB for later uses (e.g., checking the BIND response). 


Send BIND_RQ_SEND_RECORD to the other LU via the nodal NAU manager. 


BUILD_AND_SEND_BINO_RSP_NEG 


FUNCTION: Build and send a negative BIND response. 


BIND_RQ@_RCV_RECORD 
BIND_RSP_SEND_RECORD sent to NNM 


Referenced procedures, FSMs, and data structures: 


LOCAL page 4-101 
BIND_RQ_RCV_RECORD page A-21 
BIND_RSP_SEND_RECORD page A-17 


Create the BIND_RSP_SEND_RECORD to contain the negative BIND response. 
Set BINO_RSP_SEND_RECORD.LU_ID to this LU's identifier. 
Copy the PC_ID, ADDRESS, EFI, SNF, and RH from the BIND_RQ_RCV_RECORD into 
the BINO_RSP_SEND_RECORD. 
Indicate negative response in BIND_RSP_SEND_RECORD.RH (RSP, SD, NEG, and 
byte 2 of RH set to all 0's). 
Set BIND_RSP_SEND_RECORD.RU to LOCAL.SENSE_CODE followed by BIND requast code. 
Set BINO_RSP_SEND_RECORD.DCF field to appropriate value. 


Send BIND_RSP_SEND_RECORD to the LU via the nodal NAU manager. 
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BUILD_AND_SEND_BIND_RSP_POS 


Build and send a positive BIND response. 
BIND_RQ RCV_RECORD, LULU_CB 


BIND_RSP_SEND_RECORD sent to ee and BIND image returned (i.@. BIND image from 
BIND response just sent) 


Referenced procedures, FSMs, and data structures: % eat ns 7 | ie 
LUCB page A-1 


LULU_CB | a page A-5 
BIND_RQ_RCV_RECORD | page A-21 
BIND_RSP_SEND_RECORD | page A-17 
PARTNER_LU : . page A-2 


MODE fg ak a | page A-3 


Create BIND_RSP_SEND_RECORD to contain the Beuitive BIND response. 
Set BIND _RSP_ SEND _RECORD. LU_ID to this LU'’s identifier. 
Copy the PC. ID, ADDRESS, EFI, SNF, and RH from the BIND -PA_RCV_ RECORD into 
the BIND_ RSP_ SEND RECORD. 
Set BIND_ RSP_ SEND _ RECORD.RH to indicate positive response (RSP, ~SD, POS, and 
byte 2 of RH set to all 6's). 
Set BIND_RSP_SENO_RECORD.RU to the appropriate values (see page a= 25). 
Insert the random data found in the BIND_RSP_ SEND_ RECORD. RU 
into the LUCB.PENDING_RANDOM_DATA_LIST. _ 
The PARTNER_LU, MODE, and LULU. CB are used in Perea of the BIND RU. - 
Set BIND_RSP_SEND_RECORD.DCF to appropriate value. 
Send BIND _RSP SEND RECORD to the other LU via the nodal NAU manager. 
Return a copy of BIND image from the BIND response RU. 


BUILD_AND_SEND_BINDF_RQ 


FUNCTION: Build and send BINDF (BIND failure) request to SSCP (via SSCP-LU 
half-session). This procedure is used only within subarea nodes. 


INPUT: Reason code (type of BINDF to send), LULU_CB, sense data 
OUTPUT: HS_SEND_RECORD (containing BINOF request) sent to SSCP-LU half-session 


Referenced procedures, FSMs, and data structures: 
LULU_CB8 page A-5 
HS_SEND_RECORD page A-16 


If this node is a subarea node then (the BINDOF request is sent only by subarea nodes) 
Create HS_SEND_RECORD to contain the BINOF request. 
Set HS_SEND_RECORD.EFI to NORMAL. 
Set HS_SEND_RECORD.SNF to a wnique identifier. 
Set HS_SEND_RECORD.DCF to appropriate value. 
Set HS_SEND_RECORD.RH to appropriate values (Figure 4-2 on page 4-8). 
Set HS_SEND_RECORD.RU (see BINDF request in Appendix E). Set the BINDF reason 
field in accordance with the passed reason code and the BINDF sense data to the 
passed sense data parameter. The passed LULU_CB contains information (e.g.: addresses) 
used in building the RU. 


Send HS_SEND_RECORD to the CP via the CP-LU half-session. 


4-60 SNA Format and Protocol Reference Manual for LU Type 6.2 


BUILD_AND_SEND_CINIT_RSP 
BUILD_AND_SEND_CINIT_RSP 


FUNCTION: Build and send a positive or negative CINIT response. 


INPUT: HS_RCV_RECORD containing CINIT request. LOCAL.SENSE_CODE indicates what type 
of response (positive or negative) to build. 


OUTPUT: HS_SEND_RECORD (containing CINIT response) sent to CP via CP-LU half-session 


Referenced procedures, FSMs, and data structures: 


LOCAL page 4-101 
HS_RCV_RECORD page A-11 
HS_SEND_RECORD page A-16 


Create HS_SEND_RECORD to contain CINIT response. 
Copy the EFI, SNF, and RH from the HS_RCV_RECORD to the HS_SEND_RECORD. 


If LOCAL.SENSE_CODE = X'00000000' then (build a positive response) 
Set HS_SEND_RECORD.RH to indicate positive response (RSP, ~SD, POS, and 
byte 2 of RH set to all 0's). 
Set HS_SEND_RECORD.RU to the CINIT request code. 
If there are any unknown control vectors in the CINIT request RU then 
Append control vector X'FE' to the CINIT response RU (see control vectors 
in Appendix E). 


Else (build a negative response) 
Set HS_SEND_RECORD.RH to indicate negative response (RSP, SD, NEG, and 
byte 2 of RH set to all 0's). 
Set HS _SEND_RECORD.RU to the sense data (LOCAL.SENSE_CODE) followed by 
the CINIT request code. 


Set the HS_SEND_RECORD.DCF to the appropriate value. 


Send the HS_SEND_RECORD (containing the CINIT response) to the CP via the 
CP-LU half-session. 
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BUILD_AND_SEND_DACTLU_RSP 
BUILD_AND_SEND_DACTLU_RSP 
FUNCTION: Build and send a positive or negative DACTLU response. 
INPUT: DACTLU_RQ_RCV_RECORD 
OUTPUT: DACTLU_RSP_SEND_RECORD sent to CP via nodal NAU manager 


Referenced procedures, FSMs, and data structures: | : 
LOCAL : page 4-101] 


DACTLU_RSP_SEND_RECORD page A-17 
DACTLU_RQ_RCV_RECORD page A-22 


DECLARE TEMP_DOCF INTEGER; 


Create the DACTLU_RSP_SEND_RECORD to contain the DACTLU response. 

Set DACTLU_RSP_SEND_RECORD.LU_ID to this LU's identifier. 

Copy the PC_ID, ADDRESS, EFI, SNF, and RH from the DACTLU_RQ_RCV_RECORD into 
the DACTLU_RSP_SEND_RECORD. 


If LOCAL.SENSE_CODE = X‘'00000000' then (build a positive response) 
Set DACTLU_RSP_SEND_RECORD.RH to indicate positive response (RSP, -SD, POS, 
and byte 2 of RH set to all 0's). 
Set DACTLU_RSP_SEND_RECORD.RU to DACTLU request code. 
Set DACTLU_RSP_SEND_RECORD.DCF to appropriate value. 


Else (build a negative response) 
Set DACTLU_RSP_SEND_RECORD.RH to indicate negative response (RSP, SD, NEG, 
and byte 2 of RH set to all 0's). 
Set DACTLU_RSP_SEND_RECORD.RU to LOCAL.SENSE_CODE followed by the DACTLU 
request code. | | 
Set DACTLU_RSP_SEND_RECORD.DCF to appropriate value. 


Send DACTLU_RSP_SENO_RECORD to the CP via the nodal NAU manager. 


BUILD_AND_SEND_DEACTIVATE_SESS 


Build and send CTERM_DEACTIVATE_SESSION to RM. This is sent to RM when a 
CTERM-ORDERLY is received for an active LU-LU session. LNS cannot deactivate 
a@ session in an orderly manner because it does not Know when to send BIS. 
Therefore, it must tell RM to do it. 


HS: tdentitier of the haléceasion 46 be deactivated 


CTERM_DEACTIVATE_SESSION sent to RM 


Referenced procedures, FSMs, and data structures: 
CTERM_DEACTIVATE_SESSION page A-20 


Create CTERM_DEACTIVATE_SESSION record. 
Set CTERM_DEACTIVATE_SESSION.HS_ID to passed HS identifier (identifies the 
half-session to be deactivated). 


Send CTERM_DEACTIVATE_SESSION to RM. 
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BUILD_AND_SEND_HIER_RESET_RSP 
BUILD_AND_SEND_HIER_RESET_RSP 


FUNCTION: Build and send a HIERARCHICAL_RESET response to the nodal NAU manager. 


INPUT :° HIERARCHICAL_RESET 


OUTPUT: HIERARCHICAL_RESET_RSP sent to nodal NAU manager 


Referenced procedures, FSMs,» and data structures: 
HIERARCHICAL_RESET_RSP page A-18 
HIERARCHICAL_RESET page A-22 


Create HIERARCHICAL_RESET_RSP record. 
Set HIERARCHICAL_RESET_RSP.LU_ID to this LU's identifier. 
Copy the PC_ID and CP_ID fields from HIERARCHICAL_RESET into HIERARCHICAL_RESET_RSP. 


Send HIERARCHICAL_RESET_RSP to the nodal NAU manager. 


BUILD_AND_SEND_INIT_HS 


FUNCTION: Build an INIT_LHS (initialize half-session) record and send it to the 
half-session designated by the passed LULU_CB. 


INPUT: LULU_CB, BIND image, and half-session type (PRI or SEC) 


OUTPUT: INIT_HS sent to HS (LU-LU half-session) 


Referenced procedures, FSMs, and data structures: 
LULU_CB page A-5 
INIT_HS page A-16 


Create INIT_HS record. 

Set INIT_HS.PC_ID to LULU_CB.LU_LU.PC_ID (path control the LU-LU half-session will 

send to and receive from). 

Set INIT_HS.TYPE to passed half-session type parameter (primary or secondary). 

Set INIT_HS.DATA_TYPE to BIND image type (indicates data is a BIND image). 

Set INIT_HS.DATA.BIND_IMAGE to the passed BIND image (half-session protocols are based on 
fields in the BIND image). 


Send INIT_HS record to HS (the LU-LU half-session identified by LULU_CB.LU_LU.HS_ID). 


Chapter 4. LU Network Services 4-63 


BUILD_AND_SEND_INIT_R@ 


4-64 


BUILD_AND_SEND_INIT_RQ 


FUNCTION: Build and send an INIT-SELF request to the control point (SSCP or PNCP). 


INPUT: LULU_CB, DLU role (PLU or SLU) 


OUTPUT: HS_SEND_RECORD (containing INIT-SELF request) sent to CP-LU half-session 


Referenced procedures, FSMs, and data structures: | . | 
LULU_CB page A-5 
HS_SEND_RECORD page A-16 


Create HS_SEND_RECORD to contain INIT-SELF request. 

Set HS_SEND_RECORD.EFI to NORMAL. 

Set HS_SEND_RECORD.SNF to a unique identifier. 

Set HS_SEND_RECORD.RH to appropriate values (Figure 4-2 on page 4-8). 

Set HS _SEND_RECORD.RU to appropriate values (see INIT-SELF request in Appendix E). 
The choice of initiate type (I or I/Q) is installation defined. The PLU/SLU 
specification is set according to the passed DLU role parameter. 

Set HS_SEND_RECORD.DCF to the appropriate value. 


(Save information from the INIT-SELF request. This information is used to correlate 
with the INIT-SELF response [SNF] and with the CINIT or BIND request [URC]. ) 

Set LULU_CB.SENT_INITIATE_RQ.SNF to HS_SEND_RECORD.SKF. 

Set LULU_CB.SENT_INITIATE_RQ.URC to the URC field of the INIT-SELF RU. 


Send HS_SEND_RECORD to the CP via the CP-LU half-session. 


BUILD_AND_SEND_PC_CONNECT 


FUNCTION: Build and send a_ path control connect record. The purpose of this record is 
to obtain (via a response) the process ID (PC_ID) of the path control to which 
BIND will be sent and get path control characteristics necessary to build a 


BIND request. Also, for peripheral nodes only, this procedure obtains the 
address that will represent the LU-LU session being activated. For subarea 
nodes, this record may cause a virtual route to be activated. 


INPUT: LULU_CB 


OUTPUT: PC_CONNECT sent to nodal NAU manager 


Referenced procedures, FSMs, and data structures: | 
LULU_CB page A-5 
PC_CONNECT page A-18 


Create PC_CONNECT record. 
Set PC_CONNECT.LU_ID to this LU's identifier. 
Set PC_CONNECT.HS_ID to LULU_CB.LU_LU.HS_ID (half-session process identifier). 


If this node is a peripheral node then 
Set PC_CONNECT.TYPE to PERIPHERAL. 
Set PC_CONNECT.ALS to LULU_CB.LU_LU.ALS (identifies adjacent link station 
to be used for this LU-LU session). 


Else (subarea node) 

Set PC_CONNECT.TYPE to SUBAREA. 

Set PC_CONNECT.PATH_INFORMATION to the class-of-service and virtual-route-identi fier- 
list from the control vector X'0D' of the CINIT request. This information is used to 
select the virtual route. 

Set PC_CONNECT.SUBAREA_ADDRESS to the subarea portion of the address of the target LU. 


Send PC_CONNECT to path control via the nodal NAU manager. 
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BUILD_AND_SEND_PC_HS_CONNECT 


FUNCTION: Build and send a path control half-session connect record. The purpose of 
this record is to tell path control a new half-session process has’ been 
started that uses the specified address. Path control needs this 
HS_ID/ADDRESS relationship in order to route incoming PIUs and build THs for 
outgoing PIUs. 


Process identifier (PC ID) of the path control to which the PC_HS_CONNECT 
record is to be sent, process identifier (HS ID) of the half-session just 
activated, ADDRESS (address for the half-session) 


OUTPUT: PC_HS_CONNECT sent to path control via nodal NAU manager 


Referenced procedures, FSMs, and data structures: 


LNS page 4-47 
ADDRESS page A-~-34 
PC_HS_CONNECT page A-18 


Create PC_HS_CONNECT record. 

Set PC_HS_CONNECT.LU_ID to this LU's identifier. 

Set PC_HS_CONNECT.PC_ID to passed path control identifier. 
Set PC_HS_CONNECT.HS_ID to passed half-session identifier. 
Set PC_HS_ CONNECT.ADDRESS to passed ADDRESS (TH addresses). 


Send PC_HS_CONNECT to path control via the nodal NAU manager. 


BUILD_AND_SEND_PC_HS_DISCONNECT 


FUNCTION: Build and send a_ path control half-session disconnect record. This 
notify path control that a half-session 1s deactivated. 


INPUT : Half-session process identifier (HS ID) 


OUTPUT: PC_HS_ DISCONNECT sent to path control via nodal NAU manager 


Referenced procedures, FSMs, and data structures: 
PC_HS_DISCONNECT page A-19 


Create PC_HS_DISCONNECT record. 
Set PC_HS DISCONNECT.LU_ID to this LU's identifier. 
Set PC_HS_DISCONNECT.HS_ID to passed half-session identifier. 


Send PC_HS_DISCONNECT to path control via nodal NAU manager. 
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BUILD_AND_SEND_RSP_OR_LOG 


Build and send a positive or negative response to passed HS_RCV_RECORD if pos- 
sible. .If an error has oecurred and a nagative response cannot be sent, the 
error is logged. 


HS _RCV_RECORD (to be responded to), LOCAL.SENSE_| CODE anes ponzere Gailua if 
error occurred) 


HS_SEND_RECORD (containing response) sent to HS (CP-LU half-session), or error 
is ~ logged 


Referenced procedures, FSMs, and data structures: 


LOCAL | page 4-101 
HS_SENO_RECORD | | page A-16 


HS_RCV_RECORD | _ page A-11 


If HS_RCV_RECORD contains a response or a request asking for no response then 
If LOCAL.SENSE _CODE is nonzero then 
Optionally log the error. 


Else (request that requires a response) 
Create HS_SEND_RECORD to contain response. 
Set HS_ SEND _RECORD.PIU to HS_RCV_RECORD.PIU (copy batiiadt: PIU into response). 
Set HS_SEND_RECORD.RH to indicate response (RSP, BC, EC, -PAC, and byte 2 
of RH set to all 0's). 
Set HS_SEND_RECORD.RU with data other than sense data. For formatted FMD | 
requests use the 3-byte NS headers; for any non-FM0 request use the 1l-byte 
request code; otherwise, use no data. 


If LOCAL.SENSE_CODE = X'00000000' then (build positive response) 
Set HS_SEND_RECORD.RH to indicate a positive response (~SD, POS). 


Else (build negative response) 
Set HS_SEND_RECORD.RH to indicate a negative response (SO, NEG).. 
Insert LOCAL.SENSE_CODE in HS_SEND_RECORD .RU (first & eure of RU). 
Set HS_SEND_RECORD .DCF to appropriate value. 


Send HS_SEND_RECORD to the control point via the CP-LU half-session. 
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BUILD_AND_SEND_SESS_ACTIVATED 


Build and send SESSION_ACTIVATED to RM to indicate that a half-session has 
become active. It also indicates information about the half-session. 


LULU_CB 
SESSION_ACTIVATED sent to RM 


Referenced procedures, FSMs, and data structures: 
LULU_CB page A-5 
SESSION_ACTIVATED page A-20 


Create SESSION_ACTIVATED record. 

Set SESSION_ACTIVATED.HS_ID to LULU_CB.LU_LU.HS_ID (identifies half-session that 
has been activated). 

Set SESSION_ACTIVATED.SESSION_INFORMATION HALF _SESSION_TYPE to 

- LULU_CB.HALF_SESSION_TYPE (indicates primary or secondary). 

Set SESSION_ACTIVATED .SESSION_INFORMATION.BRACKET_ TYPE to LULU_CB.SESSION_TYPE 
(indicates bidder or first speaker). 

Set SESSION_ACTIVATED.LU_NAME to LULU_CB.LUNAME.LOCAL (locally known name of the 
target LU). 

Set SESSION_ACTIVATED.MODE_NAME to LULU_CB.MODENAME. 

Set SESSION_ACTIVATED.SESSION_INFORMATION.RANDOM_DATA to LULU_CB.RANDOM (random 
data sent [secondary] or received [primary)). 


Send SESSION_ACTIVATED TO RM (notify RM that an LU-LU session has been activated). 


BUTLD_AND_SEND_SESS_DEACTIVATED 


Build and send SESSION_DEACTIVATED to RM to indicate that a session has been 


deactivated. 


Process identifier (HS ID) of half-session deactivated, reason code (reason 
for deactivation) 


SESSION_DEACTIVATED sent to RM 


Referenced procedures, FSMs, and data structures: , 
SESSION DEACTIVATED page A~2]1 


Create SESSION_DEACTIVATED record. 

Set SESSION_DEACTIVATED.HS_ID to passed HS ID (identifies half-session that pas 
deactivated). 

Set SESSION_DEACTIVATED.REASON to passed reason code (indicates the reason the 
half-session was deactivated). 


Send SESSION _DEACTIVATED to RM (notify RM that an LU-LU session has been deactivated). 
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-BUILD_AND_SEND_SESSEND_RQ 


BUILD_AND_SEND_SESSEND_RQ 


FUNCTION: Build and send SESSEND request to the control point (SSCP or PNCP) to indicate 
that a session has ended. 


INPUT: LULU_CB 


OUTPUT: HS_SEND_RECORD (containing SESSEND request) sent to CP-LU half-session 


Referenced procedures, FSMs, and data structures: | 
LULU_CB page A-5 
HS_SEND_RECORD > | page A-16 


Create HS_SEND_RECORD to contain SESSEND request. 

Set HS_SEND_RECORD.EFI to NORMAL. 

Set HS_SEND_RECORD.SNF to a unique identifier. 

Set HS_SEND_RECORD. RH to appropriate values (Figure 4-2 on page 4-8). 

Set HS_SEND_RECORD.RU as specified in Appendix E. Fields from the LULU_CB 
(e.g.» addresses) are used in building this RU. 


Send HS_SEND_RECORD to the control point via the CP-LU half-session. 


BUILD_AND_SEND_SESSST_RQ 


FUNCTION: Build and send SESSST request to the control point (SSCP or PNCP) to indicate 
that a session has been activated. 


INPUT: LULU_CB 


OUTPUT: *«2_SEND_RECORD (containing canal request) sent to CP-LU nett Ses 10R 


Referenced procedures, FSMs, and data structures: 
LULU_CB page A-5 
HS _SEND_RECORD page A-16 


Create HS_SEND_RECORD to contain SESSST request. 

Set HS_SEND_RECORD.EFI to NORMAL. 

Set HS_SEND_RECORD.SNF to a unique identifier. 

Set HS_SEND_RECORD.RH to appropriate values (Figure 4-2 on page 4-8). 

Set HS_SEND_RECORD.RU as specified in Appendix E. Fields from the LULU_CB 
(e.g., addresses) are used in building this RU. 


Send HS_SEND_RECORD to the control point via the CP-LU half-session. 
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BUILD_AND_SEND_TERM_R@ 
FUNCTION: Build and send TERM-SELF raquest to the control point (SSCP or PNCP). 
INPUT : LULU_CB, DEACTIVATE_SESSION.TYPE (type of TERM-SELF to send) 


OUTPUT: HS_SEND_RECORD (containing TERM-SELF request) sent to HS (CP-LU half-session) 


Referenced procedures, FSMs, and data structures: 


HS_SENO_RECORD page A-16 
LULU_CB pege A-5 
DEACTIVATE_SESSION page A-31 


Create HS_SEND_RECORD to contain the TERM-SELF request. 

Set HS SEND_RECORD.EFI to NORMAL. 

Set HS_SEND_RECORD.SNF to a unique identifier. 

Set HS_SEND_RECORD.RH to appropriate values (Figure 4-2 on page 4-8). 

Set HS_SEND_RECORD.RU to appropriate values (see TERM-SELF request in Appendix E). 
The termination reason field is set according to the passed DEACTIVATE_SESSION.TYPE. 
Fields from the LULU_CB (e.g.» URC from the INIT-SELF request) are used in building 
this RU. 

Set HS_SEND_RECORD.DCF to the appropriate value. 


Send HS_SEND_RECORD to the CP via the CP-LU half-session. 


BUILD_AND_SEND_UNBIND_R@ 


FUNCTION: Build and send an UNBIND request. 


INPUT: LULU_CB (indicates the LU-LU session to UNBIND), UNBIND type code, sense data 
(used for format-or-protocol-error type UNBINDs only) 


OUTPUT : UNBIND_RQ_SEND_RECORD sent to nodal NAU manager 


Referenced procedures, FSMs, and data structures: 
LULU_CB | page A-5 
UNBIND_RQ_SEND_RECORD page A-19 


Create UNBIND_RQ_SEND_RECORD to contain UNSIND request. 
Set UNBIND_RQ_SEND_RECORD.LU_ID to this LU‘'s identifier. 
Set UNBIND_RQ_SEND_RECORD.PC_ID to LULU_CB.LU_LU.PC_ID (identifies path control 
through which the UNBIND will flow). 
Set UNBIND_R@_SEND_RECORD. ADDRESS to LULU_CB.LU_LU.ADDRESS (to be used in the TH 
address field). 
Set UNBIND_RQ_SEND_RECORD.EFI to EXP (expedited-flow). 
Set UNBIND_RQ_SEND_RECORD.SNF to a unique identifier. Also, save this identifier 
in LULU_CB.SENT_UNBINO_RQ.SNF (used to correlate UNBIND response). 
Set UNBIND_RQ_SEND_RECORD.DCF to the appropriate value. 
Set UNBIND_RQ_SEND_RECORD.RH to the appropriate values (Figure 4-3 an page 4-16). 
Set UNBIND_RQ_SEND_RECORD.RU to the appropriate values (see UNBINO request in Appendix E). 
The UNBIND Type field is set according to the passed UNBIND type code. If the type is 
X'FE' (format or protocol error) then the passed sense data is included in the UNBIND RU. 


Send UNBIND_RQ_SEND_RECORD to the other LU via the nodal NAU manager. 
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BUILD_AND_SEND_UNBIND_RSP 


FUNCTION: Build and send an UNBIND response. 


INPUT: UNBIND_RQ_RCV_RECORD, LOCAL.SENSE_CODE (indicates what type of response [posi-. 


tive or negative] to build) 


OUTPUT: UNBIND_RSP_SEND_RECORD sent to nodal NAU manager 


Referenced procedures, FSMs, and data structures: 


LOCAL page 4-101 
UNBIND_RQ_RCV_RECORD | page A-23 
UNBIND_RSP_SEND_RECORD page A-19 


Create an UNBIND_ RSP_SEND_RECORD. 

Set UNBIND_RSP_ SEND_ RECORD. LU_ID to this LU's identifier: 

Set UNBIND_RSP_SEND_RECORD.PC_ID to UNBIND_RQ_RCV_RECORD.PC_ID. 

Set UNBIND_RSP_SEND_RECORD.ADDRESS to UNBIND_RQ_RCV_RECORD.ADDRESS. 
Set UNBIND_RSP_SEND_RECORD.EFI to EXP. 

Set UNBIND_RSP_SEND_RECORD.SNF to UNBIND_RQ_RCV_RECORD.SKF. 
Initialize UNBIND_RSP_SEND_RECORD.RH to UNBIND_RQ_RCV_RECORD.RH. 
Indicate response RH (RSP and byte 2 of RH set to all 0's). 


If LOCAL.SENSE_CODE = X' 00000000' then 
Set UNBIND_ RSP_ SEND RECORD.RH to indicate a positive response (-SD, POS). 


Else 
Set UNBIND_RSP_SEND_RECORD.RH to indicate a negative response (SD, NEG). 


Build the UNBIND RU, including the sense data if necessary. 
Set UNBIND_RSP_SEND_RECORD.DCF to appropriate value. 


Send UNBIND_RSP_SEND_RECORD to the other LU via the nodal NAU manager. 


BUILD_AND_SEND_UNBINDF_RQ 


FUNCTION: Build and send UNBINDF request to the SSCP (for subarea nodes only). 


INPUT: Sense data (from UNBIND negative response), LULU_CB 


OUTPUT: HS_SEND_RECORD (containing UNBIND request) sent to HS (SSCP-LU half-session) 


Referenced procedures, FSMs, and data structures: 
LULU_CB page A-5 
HS_SEND_RECORD page A-16 


If this node is a subarea ede and this LU is primary then (UNBINDF is sent only by 
primary LUs in subarea nodes) 

Create HS_SEND_RECORD to contain UNBINDF request. 

Set HS_SEND_RECORD.EFI to NORMAL. 

Set HS_SEND_RECORD.SNF to a unique value. 

Set HS_SEND_RECORD.RH to the appropriate values (Figure 4-2 on page 4-8). 

Set HS_SEND_RECORD.RU to the apprcpriate values (see UNBINDF request in Appendix E). 
Set sense data in the RU to the passed sense data. Indicate UNBIND error in 
reaching SLU as the reason. Fields from the passed LULU_CB (e.g., addresses) 
are used in building this RU. 


Send HS_SEND_RECORD to the CP via the CP-LU half-session. 
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CINIT_RQ_STATE_ERROR 
CINIT_RQ_STATE_ERROR 


FUNCTION: Perform state error checking on received CINIT request. These checks are 
optional. 


INPUT: HS _RCV_RECORD (containing CINIT request), LULU_CB pointer (if null, indicates 
unsolicited CINIT; otherwise, indicates solicited CINIT) 


OUTPUT: TRUE if error; otherwise, FALSE. If TRUE, LOCAL.SENSE_CODE is set to appro- 
priate sense code. 


Referenced procedures, FSMs, and data structures: 


LU_MODE_SESSION_LIMIT_EXCEEDED page 4-76 
LOCAL page 4-101 
HS_RCV_RECORD page A-11 
PARTNER_LU page A-2 
MODE page A-3 
LULU_CB page A-5 
SESSION_TYPE page 4-101 


If the passed LULU_CB pointer contains a null value (indicating unsolicited CINIT) then 
If there are insufficient resources (e.g., storage) to start a new LU-LU session then 
Set LOCAL.SENSE_CODE to X‘'08120000' (insufficient resources). 
Return with a value of TRUE (error). 


If this LU cannot currently act as a primary LU then 
Set LOCAL.SENSE_CODE to X'083A0000' (LU not enabled). 
Return with a value of TRUE (error). 


Locate the PARTNER_LU control block in which the 
PARTNER_LU.FULLY_QUALIFIED_LU_NAME matches the 
SLU name in the CINIT request. 
If unable to locate the PARTNER_LU control block then 
Set LOCAL.SENSE_CODE to X'0835xxxx' (xxxx is the offset to SLU name). 
Return with a value of TRUE (error). 


Locate the MODE control block in which MODE.NAME matches the 
mode name in the X'0D' control vector of the CINIT request. 
If unable to locate the MODE then 
Set LOCAL.SENSE_ CODE to X'0835xxxx' Oooox is the offset to mode name 
in CINIT control vector X'0D'). | 
Return with a value of TRUE (error). 


Note: Unsolicited CINIT requests occur only when not using parallel sessions. 
The following determines whether the local LU will be the bidder or first 
speaker for the session so that the proper session limit checks can be made. 
If MODE.MIN_CONLOSERS_ LIMIT = 1 then 

Set SESSION_TYPE to BIDDER. 
Else 

Set SESSION_TYPE to FIRST_SPEAKER. 


Call LU_MODE_SESSION_LIMIT_EXCEEDED( PARTNER_LU.FULLY_QUALIFIED_LU_NAME, MODE, 
SESSION_TYPE, ACTIVE_AND_PENDING_ ACTIVE) (page 4-76). 
If the session limit will be exceeded then 
LOCAL.SENSE_CODE was set to the correct sense code by LU_MODE_SESSION_LIMIT_EXCEEDED. 
Return with a value of TRUE (error). 
Else 
Return with a value of FALSE (no error). 
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Else (solicited CINIT request) 
If LULU_CB.MODENAME # the mode name in control vector X'0D' of the CINIT request 
then (The mode name must be the same as was sent in the INIT-SELF request. ) | 
Set LOCAL.SENSE_CODE to X'0835xxxx' (xxxx is the offset to mode name in CINIT 
control vector X'0D'). 
Return with a value of TRUE (error). 


Locate the PARTNER_LU and MODE control blocks using the partner-LU name and 
mode name from the LULU_CB. These control blocks will always be found for 
solicited CINIT requests. —e 


Call LU_MODE_SESSION_LIMIT_EXCEEDED( PARTNER_LU.FULLY_QUALIFIED_LU_NAME, MODE, 
LULU_CB. SESSION _TYPE, ACTIVE_AND_PENDING_ ACTIVE) (page 4-76). 
If the session limit will be exceeded then 
LOCAL.SENSE_CODE was set to the correct sense data by LU_MODE_SESSION_LIMIT_EXCEEDED. 
Return with a value of TRUE (error). 
Else 
Return with a value of FALSE (no error). 


CLEANUP_LU_LU_SESSION 


FUNCTION: Clean up LU-LU session. This may include sending a SESSEND request to the CP 
and a PC_HS_DISCONNECT record to path control. 


INPUT: LULU_CB of session to be cleaned up 


OUTPUT: LU-LU session cleaned up 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_SESSEND_RQ page 4-68 
BUILD_AND_SEND_PC_HS_DISCONNECT page 4-65 
LULU_CB page A-5 


If SESSST has been sent to the control point then 
Call BUILD_AND_SEND_SESSEND_RQ(LULU_CB) (page 4-68). 


If PC_HS_CONNECT has been sent to path control then 
Call BUILD_AND_SEND_PC_HS_DISCONNECT( LULU_CB.LU_LU.HS_ID) (page 4-65). 


Release any resources (e.g.> buffers) held by this LU-LU session. 
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INITIALIZE_LULU_CB_ACT_SESS 
FUNCTION: Initialize an LULU_CB for an LU-LU session being activated as a result of an 
ACTIVATE_SESSION received from RM. 


oe 


INPUT: ACTIVATE_SESSION, LULU_CB (to be initialized), CP_ID (control point identifier 
associated with this session) 


OUTPUT: LULU_CB Cinitialized) 


Referenced procedures, FSMs, and data structures: 


CP_ID page A-2 
ACTIVATE_SESSION page A-31 
LULU_CB page A-5 
PARTNER_LU page A-2 


Set LULU_CB.CP_ID to passed control point identifier (CP_ID). 


Determine whether the local LU is to indicate the primary or secondary role for 
itself in INIT-SELF. An LU in a peripheral node indicates primary for 
PNCP-mediated sessions; otherwise, it indicates secondary. An LU in a subarea 
node indicates primary whenever it is capable of acting as a primary; 
otherwise, it indicates secondary. 

Set LULU_CB.HALF_SESSION_TYPE to PRI or SEC as determined above. 

Set LULU_CB.CP_LU.HS_ID to the identifier of the CP-LU half-session. 

Set LULU_CB.CORRELATOR to ACTIVATE_SESSION.CORRELATOR. 


Locate the PARTNER_LU control block using ACTIVATE_SESSION.LU_NAME. 


Set LULU_CB.LUNAME.FQ to PARTNER_LU.FULLY_QUALIFIED_LU_NAME. 
Set LULU_CB.LUNAME.LOCAL to ACTIVATE_SESSION.LU_NAME. 

Set LULU_CB.MODENAME to ACTIVATE_SESSION.MODE_NAME. 

Set LULU_CB.SESSION_TYPE to ACTIVATE_SESSION.SESSION_TYPE. 
Set LULU_CB.RANDOM to null. 
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Initialize an LULU_CB fer an LU-LU. session being activated asa result of 
receiving an unsolicited BIND request. 


~ BIND_R@_RCV_RECORD, LULU_CB (to be initialized) 


LULU_CB (initialized) 


Referenced procedures, FSMs, and data structures: | ae a 
_BIND_R@Q_RCV_RECORD ; page A-21 


PARTNER_LU | page A-2 
MODE page A-3 
LULU_CB page A-5 


Set the identifier (LULU_CB.CP_ID) of the control point sedating this LU-LU 
session. The mediating control point for peripheral nodes is identified by 
either the adjacent link station (ALS) for an SSCP or a special identifier 
sal the PNCP. The control point for subarea nodes is identified by its 
address. 


Set the CP-LU hal fseseicn identifier (LULU_CB.CP_LU.NS_ JO) 
(set to a null value if control point does not have an active session with | 
this LU). 


Locate the partner-LU control block CPARTHER_ Lu) ising the user~-data PLU name 
in BIND. 


Set LULU_CB.LUNAME.LOCAL to PARTNER _LU.LOCAL_LU_NAME. 

Set LULU_CB.LUNAME.FQ to user-data PLU name in BIND. 

Set LULU_CB.MODENAME to user-data mode name in BIND. | 

Set LULU_CB.HALF_SESSION_TYPE to SEC (BIND receiver is secondary). 


Set LULU_CB.RANDOM to null. 


If parallel sessions are supported with the partner LU then 
If BIND specifies secondary as contention winner then 
Set LULU_CB.SESSION_TYPE to FIRST_SPEAKER. | 
Else 
Set LULU_CB.SESSION_TYPE to BIDDER. 


Else (parallel sessions not supported with the partner LU) 
If MODE .MIN_CONWINNERS LIMIT = 1 then 
Set LULU_CB.SESSION_TYPE to FIRST_SPEAKER. 
Else 
Set LULU_CB.SESSION_TYPE to BIDDER. 
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Initialize an LULU_CB for an LU-LU session being activated as a result of 
receiving an unsolicited CINIT request. 


HS_RCV_RECORD (containing CINIT request), LULU_CB (to be initialized) 
LULU_CB Cinitialized) 


Referenced procedures, FSMs, and data structures: 


LULU_CB page A-5 
PARTNER_LU page A-2 
CPLU_CB page A-] 
MODE page A-3 
HS_RCV_RECORD page A-11 


Locate the CP-LU control block (CPLU_CB) using the half-session identifier 
(HS_ID) from HS_RCV_RECORD. It will always be found. 

Set LULU_CB.CP_IO to CPLU_CB.CP_ID (control point identifier). 

Set LULU_CB.CP_LU.HS_ID to CPLU_CB.HS_ID (CP-LU half-session identifier). 

Set LULU_CB.HALF_SESSION_TYPE to PRI (CINIT receiver is always primary). 


Locate the PARTNER_LU control biock using the SLU name in the CINIT request 
as a search argument. It will always be found. 

Set LULU_CB.LUNAME.LOCAL to PARTNER_LU.LOCAL_LU NAME. 

Set LULU_CB.LUNAME.FQ to the SLU name from CINIT. 

Set LULU_CB.MODENAME to the mode name in control vector X'0D' of CINIT. 

Set LULU_CB.RANDOM to null. 


Note: The CINIT request can be received only if parallel sessions are not supported. 
Locate the MODE control block using LULU_CB.MODENAME 
as a search argument. It will always be found. 


If MODE.MIN_CONLOSERS_LIMIT = 1 then 
Set LULU_CB.SESSION_TYPE to BIDDER (the local LU is bidder). 


Else 
Set LULU_CB.SESSION_TYPE to FIRST_SPEAKER (the local LU is first speaker). 
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LU_MODE_SESSION_LIMIT_EXCEEDED 


” PARA. 


FUNCTION: Determine whether or not session limits associated with a given (LU, mode 


NOTE: 


name) pair are exceeded for the given state conditions. 


If parallel sessions are not supported with the partner LU and the total ses- 
sion limit will not be exceeded, then a session-activation request specifying 
this LU as first speaker is accepted. For example, a BIND request is received 
specifying the SEC as first speaker (contention winner). The SEC LU does not 
support parallel sessions with the BIND sender and SESSION_LIMIT=1, 
MIN_CONWINNERS LIMIT=0, and MIN_CONLOSERS LIMIT=1 (these values are associated 
with the modename specified in the BIND). Even though = the 
MIN_CONWINNERS_LIMIT of 0 will be exceeded, the BIND is accepted. 


PARTNER_LU.FULLY_QUALIFIED_LU NAME, MODE, session type (in SESSION_TYPE, ACTI- 
VATE_SESSION.SESSION_TYPE> or LULU_CB.SESSION_TYPE—FIRST_SPEAKER or BIDDER), 
state (ACTIVE or ACTIVE AND PENDING ACTIVE ) 


TRUE if session limits exceeded; otherwise, FALSE. If TRUE, LOCAL.SENSE_CODE 
is set to appropriate sense data. 


Referenced procedures, FSMs, and data structures: 


LOCAL page 4-101 
MODE | page A-3 


If STATE_CONDITION = ACTIVE then 
Set BIDDER _SESSION_COUNT to the number of active bidder sessions. 
Set FSP_ SESSION. COUNT to the number of active first speaker sessions. 


Else 


Set BIDDER SESSION _COUNT to the muaber of active and enilion active 
bidder sessions. 

Set FSP_SESSION_COUNT to the number of active and pending: active first 
speaker sessions. 


Set TOTAL_LIMIT to MODE .SESSION_LIMIT. 
Set FSP_LIMIT to MODE.MIN_CONWINNERS_LIMIT. 
Set*BIDDER_LIMIT to MODE .MIN_CONLOSERS_LIMIT. 


Select based on one of the following conditions: 
When FSP_SESSION_COUNT + BIDDER_SESSION_COUNT 2 TOTAL_LIMIT 
Set LOCAL. SENSE_ CODE to X'08050000' (total session limit will be exceeded). 
When FSP_SESSION_COUNT 2 TOTAL_LIMIT - BIDDER LIMIT and 
SESSION TYPE = FIRST. SPEAKER and parallel sessions are supported with 
the partner LU (see Note in prologue) 
Set LOCAL.SENSE_CODE to X'08050001' (first speaker session limit will be 
exceeded). 
When BIDDER _SESSION_COUNT 2 TOTAL_LIMIT - FSP_LIMIT and SESSION_TYPE = BIDDER 
Set LOCAL.SENSE CODE to X' 06050001" (bidder session limit will be exceeded). 
Otherwise 
Set LOCAL.SENSE_CODE to 90000000" (session limit will not be exceeded). 


If LOCAL.SENSE_CODE = X'00000000' then 
Return with a value of FALSE (session limit will not be exceeded). 


Else 


Return with a value of TRUE (session limit will be exceeded). 
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FUNCTION: Process an ABORT_HS record received from LU-LU half-session. 


INPUT : ABORT_HS record 


Referenced procedures, FSMs, and data structures: 


FSM_STATUS page 4-94 
LOCAL page 4-101 
ABORT_HS page A~-11 
LULU_CB page A-~-5 


Determine which LU-LU session is being aborted by searching through the LU-LU 
control block list CLOCAL.LULU_CB_LIST) for an LULU_CB with a half-session 
identifier (HS_ID) matching that of the half-session that sent the ABORT_HS 
record (ABORT_HS.HS_ID). 

Xf the LULU_CB is located then 

Call FSM_STATUS( ABORT_HS, LULU_CB) (page 4-94). 


PROCESS _ACTIVATE_SESSION 


FUNCTION: Process an ACTIVATE_SESSION record received from RM. 


ACTIVATE_SESSION record 


Referenced procedures, FSMs, and data structures: 


ACTIVATE_SESSION_ERROR page 4-51 
BUILD_AND_SEND_ACT_SESS_RSP_NEG page 4~56 
INITIALIZE_LULU_CB_ACT_SESS page 4-73 
FSM_STATUS page 4-94 
ACTIVATE_SESSION page A-31 
LULU_CB page A-5 
CP_ID page A-2 
ERROR_ TYPE page 4-101 


Call ACTIVATE_SESSION_ERROR(ACTIVATE_SESSION, ERROR_TYPE, CP_ID) (page 4-51). 
If there is an error then (ERROR_TYPE is returned if error) 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( ACTIVATE_SESSION.CORRELATOR, ERROR_TYPE) 
(page 4-56). 


Else (control point identifier [CP_ID] is returned if no error) 
Create an LU-LU control block (LULU_CB) and initialize its fields. 
Call INITIALIZE _LULU_CB_ACT_SESS(ACTIVATE_SESSION, LULU_CB, CP_ID) (page 4-73). 
Call FSM_STATUS(ACTIVATE_SESSION record, LULU_CB) (page 4-94). 
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PROCESS_ACTLU_RQ 


FUNCTION: Process a received ACTLU request. 


INPUT: ACTLU_RQ_RCV_RECORD 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_PC_HS_CONNECT | page 4-65 
BUILD_AND_SEND_ACTLU_RSP_NEG | | | page 4-57 
BUILD_AND_SEND_ACTLU_RSP_POS | page 4-58 
LOCAL page 4-101 
ACTLU_RQ_RCV_RECORD page A-21 
CPLU_CB | | | page A-1 


Optionally check the ACTLU request for format errors. This includes checking the 
RH (see Figure 4-3 on page 4-16 for correct format of RH) and RU (Appendix E) for 
syntax errors. Also, if the FM profile of ACTLU is specified as 6, and this LU 
does not support 6, then it is an error. 

If there is a format error then 

Set LOCAL.SENSE_CODE to the appropriate value (Appendix G). 
Call BUILD_AND_SEND_ACTLU_RSP_NEG( ACTLU_RQ_RCV_RECORD) (page 4-57) to 
send a negative response to ACTLU. 


Else (no format error) 
Determine if a CP-LU session already exists (search for a CP-LU half-session. 
control block (CPLU_CB) with a CP_ID the same as ACTLU_RQ_RCV_RECORD.CP_ID). 
If a CP-LU session already exists then 
Set LOCAL.SENSE_CODE to X'08150000' (function already active). 
Call BUILD_AND_SEND_ACTLU_RSP_NEG( ACTLU_RQ_RCV_RECORD) (page 4-57) to 
send a negative response to ACTLU. 


Else (CP-LU session does not already exist) 
If resources (e.g., storage) are not available to create a new CP-LU 
session then | 
Set LOCAL.SENSE_CODE to X'08120000' (insufficient resources). 
Call BUILD_AND_SEND_ACTLU_RSP_NEG(ACTLU_RQ_RCV_RECORD) (page 4-57). 


Else (resources are available) 

Create a CPLU_CB to represent a new CP-LU session and insert it 
in LOCAL.CPLU_CB_LIST. 

Copy the CP_ID and PC_ID fields into the CPLU_CB from the ACTLU_RQ _RCV_RECORD. 

Set CPLU_CB.HS_ID to a unique value for the CP-LU half-session process. 

Call BUILD_AND_SEND_PC_HS_CONNECT(CPLU_CB.PC_ID, CPLU_CB.HS_ID> 
ACTLU_RQ_RCV_RECORD.ADDRESS) (page 4-65) to indicate to path 

control that a new half-session has been activated. 


Call BUILD_AND_SEND_ACTLU_RSP_POS( ACTLU_RQ_RCV_RECORD) (page 4-58) 
to send a positive response to ACTLU and cre: :e the CP-LU half-session. 
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FUNCTION: Process a received BIND request. 


INPUT: BIND_RQ_RCV_RECORD 


NOTE: It is possible for a BIND containing a URC to be received with no matching 
LULU_CB. This can occur when session outage (DACTLU-SON) occurs on the CP-LU 
session after the INIT has been sent but before the BIND is received. In this 


case, the BIND ts accepted even though there is currently no active CP-LU ses- 
sion. 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_BIND_RSP_NEG page 4-59 
BIND_RQ_ STATE_ERROR page 4-52 
INITIALIZE_LULU_CB_BIND page 4-74 
FSM_STATUS page 4-94 
LOCAL page 4-101 
BIND_RQ_RCV_RECORD page A-21 
LULU_CB page A-5 
LUCB page A-1 
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Check BIND request for basic syntax errors that would inhibit further processing 
of the BIND, including errors in the RH, the TH DCF and the BIND length fields 
(see Appendix E and Figure 4-3 on page 4-16). | 
Syntax errors are format errors and, as such» are state-independent. When a syntax 
error is found, LOCAL.SENSE_CODE is set to the appropriate sense data (X'1002' for 
overall length errors and X'0835' with offset for individual length field errors). 
Syntax error checking is required. Unrecognized control vectors must be ignored. 


If the random data received in the BIND request is 
in LUCB.PENDING_RANDOM_DATA_LIST then (required check) 
Set LOCAL.SENSE_CODE to X'O080F6051'. 
Call BUILD_AND_SEND_BIND_RSP_NEG(BIND_RQ_RCV_RECORD) (page 4-59). 
Else 


If a syntax error exists then 
Call BUILD_AND_SEND_BIND_RSP_NEG(BIND_R@_RCV_RECORD) (page 4-59). 
Optionally log the error. 


Else (no syntax error) 
Determine if a BIND request is solicited. 
A solicited BIND is one that the local LU solicited by having previously sent 
an INIT-SELF. The LULU_CBs are searched for a match on either the ADDRESS 
field in BIND_RQ_RCV_RECORD (or ADDRESS and PC_ID for peripheral nodes) 
or the URC field of the BIND RU. If a match is found on either field, the 
BIND is considered solicited. 


If the BIND is solicited then 
Optionally check BIND for semantic errors Gispendin E) and if an error exists, 
set LOCAL.SENSE_CODE with sense data reflecting error. Semantic errors are 
field content errors (e.g.» a field does not contain an allowable value). Like 
syntax errors, these errors are format errors and are state-independent. 
If a semantic error is found, LOCAL.SENSE_CODE is set to the sense data X'0835' 
with the offset to the field in error. 


Call BIND_RQ_STATE_ERROR(BIND_RQ_ RCV_RECORD) (page 4-52) 
to check for state errors. If an error is found, LOCAL.SENSE_CODE contains 
the sense data indicating the type of error. 


Call FSM_STATUS(BIND_RQ _RCV_RECORD, LULU_CB) (page 4-94). 


“Else (BIND is unsolicited--session was not initiated by this LU (see Note in prologue) ) 
Check the BIND for semantic and state errors as described above. 


If an error exists then 
Call BUILD_AND_SEND_BIND_RSP_NEG(BIND_RQ_RCV_RECORD) (page 4-59). 


Else 
Create an LU-LU half-session control block (LULU_CB) and initialize its fields. 
Call INITIALIZE_LULU_CB_BIND(BIND_R@_RCV_RECORD, LULU_CB) (page 4-74). 
Call FSM_STATUS(BIND_RQ RCV_RECORD, LULU_CB) (page 4-94). 
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Process a received BIND response. 


BIND_RSP_RCV_RECORD 


The LOCAL.SENSE_CODE is not always set by the BIND response error checking 
procedures. FSM_STATUS determines whether or not an error has occurred by 
checking for a nonzero value in the LOCAL.SENSE_CODE field. Therefore, the 
LOCAL .SENSE_CODE is set to a chammy nonzero value X'FFFFFFFF’. 


Referenced procedures, FSMs, and data structures: 


BIND_RSP_STATE_ERROR page 4-53 
FSM_STATUS page 4-94 
LOCAL page 4-101 
BIND_RSP_RCV_RECORD page A-22 
LULU_CB page A-5 
LUCB page A-}l 


Attempt to correlate the BIND response with a previously sent BIND request. 
A search is made for an LULU_CB in which LULU_CB.PC_ID = 
BIND_RSP_RCV_RECORD.PC_ID and LULU_CB.SENT_BIND_RQ.SNF = BIND_RSP_RCV_RECORD.SNF. 
If the correlation is successful then (an LULU_CB has been found) 
If LU-LU verification is active (LULU_CB. RANDOM is non-empty) then 
Remove the random data sent on the BIND request 
from LUCB.PENDING_ RANDOM _DATA_LIST. 
Check the BIND response for basic syntax errors that would inhibit further 
processing, including errors in the RH, the TH DCF and the BIND length 
fields (see Appendix E and Figure 4-3 on page 4-16). Syntax errors are format 
errors and, as such, are state-independent. These error checks are required. 


Optionally check the BIND response for semantic errors (Appendix E). Semantic 
errors are field content errors (e.g., a field does not contain an allowable 


value). Like syntax errors, these errors are format errors and are state- 
independent. 


Optionally call BIND_RSP_STATE_ERROR(BIND_RSP_RCV_RECORD, LULU_CB) (page 4-53) 
to check for state errors. 


If either a syntax, semantic, or state error is detected then 
Set LOCAL.SENSE_CODE to the value X'FFFFFFFF' (see Note in prologue). 


If the random data received in the BIND response is found itn the 
LUCB. PENDING RANDOM _DATA_LIST then 
Set LOCAL.SENSE_CODE to the value X'FFFFFFFF'. 
Call FSM_STATUS(BIND_RSP_RCV_RECORD, LULU_CB) (page 4-94). 


Else (unable to correlate the BIND response) 


Set LOCAL.SENSE_CODE to X'200E0000' (response correlation error). 
Optionally log the error. 
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PROCESS_CINIT_RQ 


FUNCTION: Process a received CINIT request. 


INPUT: HS_RCV_RECORD containing CINIT request 


Referenced procedures, FSMs, and data structures: 
BUILD_AND_SEND_CINIT_RSP 
CINIT_RQ_STATE_ERROR 
INITIALIZE_LULU_CB_CINIT 
FSM_STATUS 
LOCAL 
HS_RCV_RECORD 
LULU_CB 
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page 


page 
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4-61 
4-71 
4-75 
4-94 
4-101 
A-11 
A-5 


PROCESS _CINIT_RQ 


Note: Peripheral nodes receive CINIT from the PNCP only when initiating a session 
with a peer T2.1 LU (i.e., the session is PNCP-mediated). 
If the local node is a peripheral node ark] ihe CINIT request has been received from 
an SSCP (as opposed to a PNCP) then 
Set LOCAL.SENSE_CODE to X'10030000' (function not supported). 
Call BUILD_AND_SEND_CINIT_RSP(HS_RCV_RECORD) (page 4-61) 
to send a negative response to CINIT. 
Optionally log the error. | 


Else 
Optionally check the CINIT request for syntax errors. This includes checking 
the TH DCF field and length fields within the CINIT RU. If the DCF is 
incorrect, sense data X'10020000' is used; otherwise, X'0835xxxx' is used 
(xxxx is the offset to the field in error). An additional check is made to 
determine whether the URC field (within the BIND image in CINIT) is present 
if required. See CINIT request in Apperciix E for correct format. 
If there is a syntax error then 
Set LOCAL.SENSE_CODE to appropriate value. 
Call BUILD_AND_SENOD_CINIT_RSP(HS_RCV_RECORD) (page 4-61) 
to send a negative response to CINIT. 
Optionally log the error. 


Else (no syntax error) 

If the CINIT request indicates either third-party-initiated CINITIATE origin 
specifies ILU is not OLU) or secondary-LU-initiated (SLU is OLU) then 
(unsolicited CINIT processing) 

Optionally check the CINIT request for semantic errors. This includes chacking 
that the proper session keys and control vectors are included. The sense 
data X'0835xxxx' is used to indicate fields in error Ooox is the offset to the 
field in error). See CINIT request in Appendix E for correct RU values. 
Optionally perfore CINIT state checks by calling CINIT_R@_STATE_ERROR 
(HS_RCV_RECORD, LULU_CB pointer) (page 4-71). If any errors are 
found LOCAL.SENSE_CODE is set to the appropriate sense data. 
If there is a semantic or state error then 
Call BUILD_AND_SEND_CINIT_RSP(HS_RCV_RECORD) (page 4-61) 
to send a negative response to CINIT. 


Else (no errors) 
Create and initialize an LU-LU half-session control block (LULU_CB). 
Call INITIALIZE _LULU_CB_CINIT(HS_RCV_RECORD, LULU_CB) (page 4-75). 
Call FSM_STATUS(CHS_RCV_RECORD, LULU_CB) (page 4-94). 


Else (not unsolicited CINIT) 

Attempt to correlate this CINIT request to a previously sent INIT-SELF 
request to the same CP. Search for an LU-LU half-session control 
block (LULU_CB) where LULU_CB.SENT_INITIATE_RQ.URC = the URC field in 
the BIND image of the CINIT request. 

If the CINIT request is correlated successfully then (solicited CINIT 
processing) 

Check for CINIT request semantic and state errors as described above. 
If an error is found, LOCAL.SENSE_CODE is set. 
Call FSM_STATUS(HS_RCV_RECORD, LULU_CB) (page 4-94). 


Else (unable to correlate CINIT) 
Set LOCAL.SENSE CODE to X'081E0000' {session reference error). 
Call BUILD_AND_SENO_CINIT_RSPCHS_RCV_RECORD) (page 4-61) 
to send a negative response to CINIT. 
Optionally log the error. 
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PROCESS_CLEANUP_RQ 


FUNCTION: Process a CLEANUP request received by a subarea LU. 


INPUT: HS_RCV_RECORD containing CLEANUP request 


Referenced procedures, FSMs, and data structures: | | ra 4 
BUILD_AND_SEND_RSP_OR_LOG = page 4-66 


FSM_STATUS | page 4-94 
LOCAL | page 4-101 
LULU_CB page A-5 
HS_RCV_RECORD | | page A-11 


Optionally check the CLEANUP request for format errors. This includes 
checking the TH DCF field for RU length errors (X‘'10020000'), checking for 
format 0 (X'10030000'), and checking for valid session Keys (X‘0835xxxx' ). 
See CLEANUP request in Appendix E for correct format. 

If there is a format error then 

Set LOCAL.SENSE_CODE to the appropriate value. 
Call BUILD_AND_SEND_RSP_OR_LOG(HS_RCV_RECORD) (page 4-66) 
to send a negative response to CLEANUP. 


Else (no format error) 
Determine the LU-LU session (mediated by the CP that sent the CLEANUP) 
to be cleaned up by searching for an LU-LU half-session control | 
block (LULU_CB) that has an address pair (LULU_CB.ADDRESS) 
matching the address pair specified in the CLEANUP RU. (The addresses 
of the address pair in CLEANUP may be specified in any order. ) 
If an LULU_CB is found then 
Call BUILD_AND_SEND_RSP_OR_LOG(HS_RCV_RECORD ) (page 4-66) 
to send a positive response to CLEANUP. 
Call FSM_STATUS(HS_RCV_RECORD, LULU_CB) (page 4-94). 


Else (unable to determine which LU-LU session to clean up) ) 
Set LOCAL.SENSE_CODE to X‘'081E0000' (session reference error). 
Call BUILD_AND_SEND_RSP_OR_LOG(HS_RCV_RECORD) (page 4-66) 

to send a negative response to CLEANUP. 
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' FUNCTION: Process a CTERM request received by a subarea LU. 


INPUT: HS_RCV_RECORD containing CTERM request 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_RSP_OR_LOG page 4-66 
FSM_STATUS page 4-94 
LOCAL page 4-101 
LULU_CB page A-5 
HS_RCV_RECORD page A-11 


Optionally check the CTERM for format errors. This includes checking 
the TH DCF field (X'10020000'), the Format and Type fields (X'10030000'), 
and the Session Key field (X‘'0835xxxx'). See CTERM request in Appendix E 
for correct format. 
If there is a format error then 
Call BUILD_AND_SEND_RSP_OR_LOG(HS_RCV_RECORD) (page 4-66) 
to send a negative response to CTERM. 


Else (no format error) 

Determine the LU-LU session (mediated by the CP that sent the CTERM) 
to be cleaned up by searching for an LU-LU half-session control 
block (LULU_CB) that has an address pair (LULU_CB.ADDRESS) 
matching the address pair specified in the CTERM RU. (The addresses 
of the address pair in CTERM may be specified in any order.) 

If an LULU_CB if found then 

Call BUILD_AND_SEND_RSP_OR_LOG(HS_RCV_RECORD) (page 4-66) 
to send a positive response to CTERM. 
Call FSM_STATUS(HS_RCV_RECORD, LULU_CB) (page 4-94). 


Else (unable to determine which LU-LU session to clean up) 
Set LOCAL.SENSE_CODE to X'081E0000' (session reference error). 
Call BUILD_AND_SEND_RSP_OR_LOG(HS_RCV_RECORD) (page 4-66) 
to send a negative response to CTERM. 
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PROCESS_DACTLU_RQ 


FUNCTION: Process a received DACTLU request. 


INPUT: DACTLU_R@_RCV_RECORD 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_DACTLU_RSP page 4-62 
BUILD_AND_SEND_PC_HS_DISCONNECT page 4-65 
FSM_STATUS page 4-94 
LOCAL page 4-101 
DACTLU_RQ_RCV_RECORD page A-22 
CPLU_CB page A-] 


Optionally check the DACTLU request for RH format errors (see Figure 4-3 on page 4-16 for 
correct RH format). 
If an error is found then 
Set LOCAL.SENSE_CODE to the appropriate value (Appendix 6G). 
Call BUILD_AND_SEND_DACTLU_RSP(DACTLU_RQ_RCV_RECORD) (page 4-62) 
to send a negative response to the DACTLU request. 


Else (no error found) 

Call BUILD_AND_SEND_DACTLU_RSP(DACTLU_RQ_RCV_RECORD) (page 4-62) 
to send a positive response to the DACTLU request. 

Determine if a CP-LU session is active by searching for a CPLU_CB (in 
LOCAL.CPLU_CB_LIST) to determine whether DACTLU_RQ_RCV_RECORD and CPLU_CB have 
matching control point identifiers. 

If a CP-LU session is active then 

If the DACTLU RU length is less than 3 or the DACTLU deactivation type is 
normal then 

Reset all active and pending active LU-LU sessions mediated by this 

CP by calling FSM_STATUS (page 4-94) with a 

RESET_NORMAL input for each LU-LU session. 


Else (must be DACTLU with type SON) 
Reset all LU-LU sessions that have not become active or pending active by 
calling FSM_STATUS (page 4-94) with a RESET_SON 
input for each LU-LU session. 


Destroy the CP-LU half-session process. 


Call BUILD_AND_SEND_PC_HS_DISCONNECT(CPLU_CB.HS_ID) (page 4-65) 
to notify path control that a half-session has been deactivated. 
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PROCESS _DEACTIVATE_SESSION 


FUNCTION: Process a DEACTIVATE_SESSION record received from RM. 


INPUT: DEACTIVATE_SESSION record 


Referenced procedures, FSMs, and data structures: 


FSM_STATUS page 4-94 
DEACTIVATE_SESSION page A-31 
LULU_CB page A-5 


If RM is deactivating a pending-active session (DEACTIVATE_SESSION.STATUS = 
PENDING) then 
Attempt to locate the LU-LU half-session control block (LULU_CB) using the 
DEACTIVATE_SESSION.CORRELATOR field. 


Else (RM is deactivating an active session--from its perspective) 
Attempt to locate the LU-LU half-session control block (LULU_CB) using the 
DEACTIVATE_SESSION.HS_ID field. 


If an LULU_CB has been located then 
Call FSM_STATUS(DEACTIVATE_SESSION, LULU_CB) (page 4-94). 


PROCESS_ECHOTEST_RQ 


FUNCTION: Process a received ECHOTEST request in an implementation-defined way. 


INPUT: HS _RCV_RECORD containing ECHOTEST request 


Referenced procedures, FSMs, and data structures: 
HS_RCV_RECORD page A-11 


See page 4-31. 


PROCESS HIERARCHICAL_RESET 


FUNCTION: Process a HIERARCHICAL_RESET record received from the nodal NAU manager. This 
record is generated as a result of a DACTPU. 


INPUT: HIERARCHICAL_RESET record 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_HIER_RESET_RSP page 4-63 
FSM_STATUS page 4-94 
HIERARCHICAL_RESET page A-22 
CPLU_CB page A-1 


Attempt to locate the CP-LU session control block by searching for a CPLU_CB 
with a control point identifier matching that in the HIERARCHICAL_RESET record. 
If a CPLU_CB is located then 
Reset all LU-LU sessions mediated by this CP by calling FSM_STATUS 
(page 4-94) with a RESET_NORMAL input for each LU-LU session. 
Destroy the CP-LU half-session. 


Call BUILD_AND_SEND_HIER_RESET_RSP({HIERARCHICAL_RESET) (page 4-63). 
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PROCESS_INIT_HS_RSP 


FUNCTION: Process an INIT_HS_RSP record received from an LU-LU half-session. 


INPUT: INIT_HS_RSP record 


Referenced procedures, FSMs, and data structures: 


FSM _ STATUS page 4-94 
INIT_HS_RSP page A-i1 


LULU_CB | page A-5 


Attempt to locate the LU-LU half-session control block (LULU_CB) associated 
with the half-session that sent the INIT_HS_RSP. Search the list of LULU_CBs 
for one with a half-session identifier (HS_ID) matching that of the half-session 
the INIT_HS_RSP was received from. 
If an LULU_CB is located then 
Call FSM_STATUSCINIT_HS_RSP, LULU_CB) (page 4-94). 


PROCESS_INIT_SELF_RSP 


FUNCTION: Process a received INIT-SELF response. 


HS_RCV_RECORD containing INIT-SELF response 


Referenced procedures, FSMs, and data structures: 


FSM_STATUS page 4-94 
HS_RCV_RECORD page A-11 
LULU_CB page A-§ 


Attempt to correlate the INIT-SELF response with a sent INIT-SELF request. 
Search for an LU-LU control block (LULU_CB) where LULU_CB.CP_LU.HS_ID = 
HS_RCV_RECORD.HS_ID and LULU_CB.SENT_INITIATE_RQ.SNF = HS_RCV_RECORD.SNF. 

If the response is correlated successfully then 

Call FSM_STATUS(HS_RCV_RECORD, LULU_CB) (page 4-94). 


Else 
Optionally log the error using sense data X'200E0000'. 
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PROCESS_NOTIFY_RQ 


FUNCTION: Process a received NOTIFY request. 
INPUT: HS_RCV_RECORD containing NOTIFY «equest 


Referenced procechiras, FStts, and data structures: 
BUILD_AND_SEND_RSP_OR_LOG 


page 4-66 
FSM_STATUS page 4-94 
LOCAL page 4-101 
HS_RCV_RECORD page A-11 
LULU_CB page A-5 


Optionally check the NOTIFY request for format errors. This includes 
checking the TH DCF and length fields (X'10020000'), the vector type 
('0835xxxx'), and the session Keys (X'0835xxxx') (where xxxx 1s an offset 
in each case). See NOTIFY request in Appendix E for correct format. 

If there is a format error then 


Set LOCAL.SENSE_CODE to the appropriate value. 
Call BUILD_AND_SEND_RSP_OR_LOG(HS_RCV_RECORD) (page 4-66) 
to send a negative response to NOTIFY. 


Else (no format error) 
Attempt to correlate this NOTIFY request with a previously sent INIT-SELF 
request (for the same CP). Search for an LU-LU half-session control block 


(LULU_CB) where LULU_CB.SENT_INITIATE_RQ.URC matches the URC field in the 
NOTIFY request RU. 


If an LULU_CB is found then 
Call FSM_STATUS(HS_RCV_RECORD, LULU_CB) (page 4-94). 


Else (unable to correlate the NOTIFY request) 
Set LOCAL.SENSE_CODE to X'O081E0000° (session reference error). 


Call BUILD_AND_SEND_RSP_OR_LOG(HS_RCV_RECORD) (page 4-66) 
to send a negative response to NOTIFY. 


PROCESS_NOTIFY_RSP 


FUNCTION: Process a received NOTIFY response. 


INPUT: HS_RCV_RECORD containing received NOTIFY response. 


Referenced procedures, FSMs, and data structures: 


HS_RCV_RECORD page A-11 


See page 4-13 for a general discussion; details are not formally defined. 
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PROCESS_PC_CONNECT_RSP 


4, 


FUNCTION: Process a path control conmmect response (PC_CONNECT_RSP) raceived from NNM. 
‘INPUT: = PC_CONNECT_RSP 


Referenced procedures, FSMs, and data structures: 


FSM_STATUS page 4-94 
PC_CONNECT_RSP | page A-22 


Attempt to locate the LU-LU half-session control block (LULU_CB) in which the 
half-session identifier (HS_ID) matches that in the PC_CONNECT_RSP record. 
If an LULU_CB is located then 

Call FSM_STATUS(PC_CONNECT_RSP, LULU_CB) (page 4-94). 


PROCESS_REQECHO_RSP 


FUNCTION: Process a received REQECHO response in an implementation-defined way. 


INPUT: HS_RCV_RECORD containing received REQECHO response 


Referenced procedures, FSMs, and data structures: 
HS_RCV_RECORD page A-11 


See page 4-3]. 


PROCESS_SESSION_ROUTE_INOP 


FUNCTION: Process a SESSION_ROUTE_INOP record received from NNM. 


SESSION_ROUTE_INOP 


Referenced procedures, FSMs, and data structures: 


FSM_STATUS page 4-94 
SESSION_ROUTE_INOP | page A-23 
LULU_CB | page A-5 
CPLU_CB | | , | page A-1} 


Reset all CP-LU sessions that are using the path control process that failed. 
This is done by lecating all the CP-LU session control blocks (CPLU_CBs) 
that have a path control identifier (PC_ID) matching that of the path 
control process that failed. Each CPLU_CB located is then destroyed. 


Reset all LU-LU sessions that are using the path control process that failed. 
This is done by locating all the LU-LU session control blocks (LULU_CBs) 
that have a path control identifier (PC_ID) matching that of the path 
control process that failed. For each LULU_CB located, 

FSM_STATUS (page 4-94) is called with a RESET_NORMAL input 
to reset that session. 
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PROCESS_TERM_SELF_RSP 


FUNCTION: Process a received TERM-SELF response. Nothing is done for a TERM-SELF 
response because the LU-LU session awareness is cleaned up when the TERM-SELF 
request 1s sent. The TERM-SELF response is simply discarded. 


HS_RCV_RECORD containing TERM-SELF response 


Referenced procedures, FSMs, and data structures: 
HS_RCV_RECORD page A-11 


No processing is done for a TERM-SELF response. 


PROCESS_UNBIND_RQ 


FUNCTION: Process a received UNBIND request. 


INPUT: UNBIND_R@Q RCV_RECORD 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_UNBIND_RSP page 4-70 
FSM_STATUS page 4-94 
LOCAL page 4-101 
UNBIND_RQ_ RCV_RECORD page A-23 
LULU_CB page A-5 
LUCB page A-l 


Setionally check the UNBIND request for syntax errors. Syntax errors include checking 
the RH (see Figure 4-3 on page 4-16 for correct format) and checking the length 
(DCF) for being too short (see UNBIND request in Appendix E). 
If there is a syntax error then 
Set LOCAL.SENSE_CODE to appropriate value. 
Call BUILD_AND_SEND_UNBIND_RSP(UNBIND_RQ_RCV_RECORD ) 
(page 4-70) to send a negative response to UNBIND. 
Optionally log the error. 


Else (no syntax error) 
Attempt to correlate the UNBIND with an existing LU-LU session by locating an LULU_CB 
where LULU_CB.LU_LU.PC_ID = UNBIND_R@ _RCV_RECORD.PC_ID and 
LULU_CB.LU_LU.ADDRESS = UNBIND_RQ RCV_RECORD.ADDRESS. 
If the UNBIND correlates to an existing session (an LULU_CB is found) then 
Call FSM_STATUS(UNBIND_RQ RCV_RECORD, LULU_CB) (page 4-94). 


Else (UNBIND does not correlate to an existing session) 
Call BUILD_AND_SEND_UNBIND_RSP( UNBIND_RQ_RCV_RECORD ) 
(page 4-70) to send positive response to UNBIND. 
If LU-LU verification is active (LULU_CB.RANDOM is non-empty) then 
Remove the random data found 1n LULU_CB.RANDOM 
from LUCB.PENDING_RANDOM_DATA_LIST. 
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PROCESS_UNBIND_RSP 


FUNCTION: 


Process a received UNBIND response. 


INPUT : UNBIND_RSP_RCV_RECORD 


Referenced procedures, FSMs, and data structures: 


FSM_STATUS page 4-94 
LULU_CB page A-5 
UNBIND_RSP_RCV_RECORD 


page A-23 
Optionally check the UNBIND response RH for format errors 


(see Figure 4-3 on page 4-16 for correct format of RH). 
If there is an RH error then 


Optionally log the error. 


Else (no RH error) 


Correlate this UNBIND response with a sent UNBIND request. Search for an 
LU-LU half-session control block (LULU_CB) where LULU_CB.LU_LU.PC_ID 
UNBIND_RSP_RCV_RECORD.PC_ID and LULU_CB.SENT_UNBIND_RQ.SNF = 
UNBIND_RSP_RCV_RECORD.SNF. 

If the UNBIND response is correlated successfully then 

Call FSM_STATUS(UNBIND_RSP_RCV_RECORD, LULU_CB) (page 4-94). 


Else (unable to correlate UNBIND response) 
Optionally log the error with sense data X'200E0000' (response correlation error). 
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FSM_STATUS 


FUNCTION: 


NOTE: 


INPUT: 


This FSM maintains the state of an LU-LU session from initiation through ter- 
mination. State name abbreviations are as follons: 


® RES = reset 

® PND INI RSP PLU = pending receipt of INTT-SELF response where INIT-SELF 
was sent specifying this LU as PLU 

® PND INI RSP SLU = pending receipt of INIT-SELF response where INIT-SELF 
was sent specifying this LU as SLU 

® PND CIN = pending receipt of CINIT request 

@® PND BIN = pending receipt of BIND request 

® PND PC RSP THI = pending receipt of PC_CONNECT_RSP for a session this LU 
initiated (sent INIT-SELF for) 

® PNO BIN RSP THI = pending receipt of a BIND response for a session this LU 
initiated (sent INIT-SELF for) | 

@e PND INI HS RSP THI = pending receipt of INIT_HS_RSP for a session this LU 
initiated (sent INIT-SELF for) 

@ PND PC RSP OTH = pending receipt of PC_CONNECT_RSP for a session the other 
LU initiated (sent INIT-SELF for) 

* PND BIN RSP OTH = pending receipt of a BIND response for a session the 
other LU initiated (sent INIT-SELF, for) 

® PND INI HS RSP OTH = pending receipt of INIT_HS_RSP for a session the oth- 
er LU initiated (sent INIT-SELF for) 

® ACT = active 

® PND UNB RSP = pending UNBIND response 


The state of the LU-LU session may be considered "active" or "pending active." 
States 8, 11, 12, and 13 are considered "active." States 6, 7, 9, and 10 are 
considered "pending active." All other states are considered neither "active" 
nor "pending active." 


Error type is "retry" if LOCAL.SENSE_CODE has one of the following values (an 
asterisk may stand for any hexadecimal digit): 


O80 ] 1% 
O8O5xHKK 
O81 2xH«x 
083 7%KKX 
O83 OHHH 
0842 "Kx 
O845xKKK 
O84BxxKH 
0856 x 
0857 xHKH 
800 1 HHH 
BOOS KHRH 
BOO SHRRN 
8013%*00 
8013*#03 
8013%*04 
8013*x05 
8013**06 


eesceaoeneea_ee2e2eee2080808020 86 


For any other value of LOCAL.SENSE_CODE error type is "no retry". 


The record to be processed and the LU-LU half-session control block (LULU_CB). 
The input record is used as an input to this FSM. These inputs denote RUs 
(Appendix E), interprocess records (iji.e., from HS, RM, or NNM [Appendix Al), 
results of earlier sense data settings (OK, if LOCAL.SENSE_CODE mas set to 
00000000; NG, otherwise), and session roles (PLU or SLU) of the local LU (as 
TLU). 


SNA Format and Protocol Reference Manual for LU Type 6.2 


FSM_STATUS 


Referenced procedures, FSMs, and data structures: 


BUILD_AND_SEND_DEACTIVATE_SESS page 4-62 
BUILD_AND_SEND_UNBINDF_RQ page 4-70 
BUILD_AND_SEND_BIND_RSP_NEG page 4-59 
BUILD_AND_SEND_BIND_RSP_POS page 4-60 
BUILD_AND_SEND_UNBIND_RQ page 4-69 
BUILD_AND_SEND_INIT_HS page 4-63 
BUILD_AND_SEND_ACT_SESS_RSP_POS page 4-57 
BUILD_AND_SEND_SESS_ACTIVATED page 4-67 
CLEANUP_LU_LU_SESSION page 4-72 
BUILD_AND_SEND_BINDF_RQ page 4-60 
BUILD_AND_SEND_TERM_RQ page 4-69 
BUILD_AND_SEND_UNBIND_RSP page 4-70 
BUILD_AND_SEND_INIT_RQ page 4-64 
BUILD_AND_SEND_ACT_SESS_RSP_NEG page 4-56 
BUILD_AND_SEND_PC_HS_ CONNECT page 4-65 
BUILD_AND_SEND_PC_CONNECT page 4-64 
BUILD_AND_SEND_PC_HS_DISCONNECT page 4-65 
BUILD_AND_SEND_RSP_OR_LOG page 4-66 
BUILD_AND_SEND_SESSST_RQ page 4-68 
BUILD_AND_SEND_BIND_RQ page 4-59 
BUILD_AND_SEND_CINIT_RSP page 4-61 
BUILD_AND_SEND_SESS_DEACTIVATED page 4-67 
DEACTIVATE_SESSION page A-31 

BIND_R@Q_RCV_RECORD page A-2] 

UNBIND_RQ_RCV_RECORD page A-23 
UNBIND_RSP_RCV_RECORD page A-23 
PC_CONNECT_RSP page A-22 
INIT_HS_RSP page A-11 

ABORT_HS page A-11 

HS_RCV_RECORD page A-11 

LULU_CB page A-5 

LOCAL page 4-101 
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OUTPUT | FUNCTION | | 


Call BUILD_AND_SENO_PC_HS_DISCONNECT( LULU_CB.LU_LU.HS_ID) (page 4-65). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


o 
aE 


If DEACTIVATE_SESSION. TYPE = NORMAL then 
Call BUILD_AND_SEND_UNBIND RQ(LULU_CB, NORMAL, X'00000000') (page 4-69). 
Else 
Call BUILD_AND_SEND_UNBIND_RQ(LULU_CB, FORMAT_OR_PROTOCOL_ERROR, 
DEACTIVATE_SESSION.SENSE_CODE) (page 4-69). 


If either node's path control does not support segmenting and the primary send 
maximum RU size in the BIND response is greater than the link segment size then 
Set the maximum RU size to the link maximus RU segment size. 


If the BIND response specifies the primary as contention winner then 
Set LULU_CB.SESSION_TYPE to FIRST_SPEAKER. 

Else 
Set LULU_CB.SESSION_TYPE to BIDDER. 


Call BUILD_AND_SEND_SESSST_R@(LULU_CB) (page 4-68). 
Call BUILD_AND_SEND_INIT_HS(LULU_CB, BIND image from BIND response RU, PRI) 
(page 4-63). 


Call BUILD_ANO_SENO_ACT_SESS_RSP_POS( LULU_CB) (page 4-57). 


Set fields in LULU_CB from BIND request record (ADDRESS, ALS [peripheral nodes 
only], PC_ID, and user-data session-instance identifier). 

Create LU-LU half-session with wiique identifier (save identifier in 
LULU_CB.LU_LU.HS_ID). 

Call BUILD_AND_SEND_PC_HS CONNECT( LULU_CB.LU_LU.PC_ID, LULU_CB.LU_LU.HS_ ID, 
LULU_CB.LU_LU.ADDRESS) (page 4-65). 

Call BUILD_AND_SENO_BIND_RSP_POS(BIND_RQ_RCV_RECORD, LULU_CB) (negotiated 
BIND image returned, page 4-60). 

Call BUILD_ANO_SEND_SESSST_RQ(LULU_CB) (page 4-68). 

Call BUILD_AND_SEND_INIT_HS(LULU_CB, negotiated BIND image, SEC) 

(page 4-63). 


If this node is a peripheral node then 
Set LULU_CB.LU_LU.ADDRESS to PC_CONNECT_RSP.ADDRESS to save the assigned 
address for later use. Subarea nodes obtain the address from the CINIT request. 
Call BUILD_AND_SENO_PC_HS_CONNECT( LULU_CB.LU_LU.PC_ID, LULU_CB.LU_LU.HS_I0, 
LULU_CB.LU_LU. ADDRESS) (page 4-65). 
Call BUILD_AND_SEND_BIND_RQ(LULU_CB) (page 4-59). 


Call BUILD_AND_SENO_SESS_ACTIVATED(LULU_CB) (page 4-67). 


Call BUILD_AND_SEND_UNBIND_RQ(LULU_CB, FORMAT_OR_PROTOCOL_ERROR, 
INIT_HS_RSP.SENSE_CODE) (page 4-69). 


Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Call BUILD_ANO_SENOD_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, NO_RETRY); 
(page 4-56). 

Call BUILD_AND_SEND_UNBIND_RQ(LULU_CB, FORMAT_OR_ PROTOCOL_ERROR, 
INIT_HS_RSP.SENSE_CODE) (page 4-69). 


Call BUILD_AND_SEND_TERM_RQ( LULU_CB, DEACTIVATE_SESSION.TYPE) (page 4-69). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Call BUILD_ANO_ SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, RETRY) 
(page 4-56). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Call BUILD_AND_SEND_UNBIND_RQ(LULU_CB, FORMAT_OR_PROTOCOL_ERROR» 
ABORT_HS.SENSE_CODE) (page 4-69). 

| Call BUILD_AND_SEND_SESS_DEACTIVATED( LULU_CB.LU_LU.HS_ID, ABNORMAL_NO_RETRY) 

(page 4-67). 
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Call BUILD_AND_SEND_BINDF_RQ( SETUP_REJECT_AT_SLU, LULU CB, ‘LOCAL. SENSE CODE ) 
(page 4-60). 
Call CLEANUP_LU_LU_SESSION( LULU_CB) 


(page 4-72). 


Call BUILD_AND_SEND_UNBSIND_RSP(UNBIND_R@Q _RCV_RECORD, LULU_CB_PTR) 
(page 4-70). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Call BUILD_AND_SEND_UNBIND_RQ(LULU_CB, INVALID_PARMS, X'00000000' ) 
(page 4-69). 


If LOCAL.SENSE_CODE = X‘'00000000' then 

Set LOCAL.SENSE_CODE = X‘'08090000' (mode inconsistency). 
Call BUILD _AND_SEND_RSP_OR_LOG(HS_RCV_RECORD) 
(send -RSPC(NOTIFY), page 4-66). 


Call BUILD, AND_SEND_UNBIND_RSP( UNBIND_RQ_RCV_RECORD, LULU_CB_PTR) 
(page 4-70). 

Determine the reason for the session deactivation. If the UNBIND type is normal or 
BIND forthcoming, the reason is NORMAL. If the UNBIND type is invalid session 
parameters, or LU failure unrecoverable, or format or protacol error; 
the reason is ABNORMAL_NO_RETRY. . | 

For all other UNBINOD types, the reason is ABNORMAL_RETRY. 

Call BUILD_AND_SENO_SESS_DEACTIVATED( LULU_CB.LU_LU. HS_ ID, reason) 

(page 4- 67). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Call BUILD_AND_SENO_UNBINO_RQ(LULU_CB, CLEANUP, X'00000000') (page 4-69). 
(Send UNBIND(CLEANUP), page 4-69). 


Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Call esta AND_SENO_INIT_RQ( LULU_CB, SLU) (page 4-64). 
Call BUILD ~AND _SENO_INIT_RQ(LULU_CB, PLU) (page 4- 64). 


Call BUILD_AND_SEND_ RSP_ OR_LOGCHS_RCV_RECORD ) (send tRSP(NOTIFY), page 4-66). 
Determine the error type by examining the sense data in the NOTIFY request 
(see Note in prologue). | 
Call BUILD _AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, error type) 
(page 4-56). | 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Call BUILD_AND_SEND_UNBIND_RQ@(LULU_CB, INVALID_PARMS, X'00000000' ) 
(page 4-69). 

Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, NO_RETRY) 
(page 4-56). 


If LOCAL.SENSE_CODE = X'00000000' then 
Set LOCAL.SENSE_CODE to X‘'08150000' (function already active). 
Call BUILD_AND _ SEND _CINIT_RSPCHS_RCV_RECORD) (page 4-61). 


Call BUILD, AND_SENDO_UNBINDF_RQ(sense data from UNBIND_RSP_RCV_RECORD, LULU_CB) 
(page 4-70). 
Call CLEANUP_LU_LU_SESSION( LULU_ cB) (page 4-72). 


Determine the error type by examining the sense data in the INIT-SELF response 
(see Note in prologue). 

Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, error tyre) 
(page 4-56). 


Call CLEANUP_LU_ LU_ SESSION(LULU_CB) (page 4-72). 


Call BUILD_AND_SEND_| CINIT_ RSPCHS_ RCV RECORD) (page 4-61) to send +RSP(CINIT). 
Create a new half-session (HS) process. 

Call BUILD_AND_SENOD_PC_CONNECT(LULU_CB) (page 4-64), 
Save “ CINIT request in the LULU_ cB for later use in building the BIND request. 


Call BUILD_ANO_SENO_ACT_SESS_RSP_NEG¢ LULU_CB.CORRELATOR, RETRY) 

(page 4-56). 
Call BUILD_AND_SEND_PC_HS_ DISCONNECT( LULU_CB.LU_LU.HS_ID) (page 4-65). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 
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Call BUILD_AND_SEND_UNBIND_RQ(LULU_CB, CLEANUP, X'00000000') (page 4-69) 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, RETRY) 


(page 4-56). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


If LOCAL.SENSE_CODE = X'00000000' then 
Set LOCAL.SENSE_CODE = X'08150000' (function already active). 


Call BUILD_AND_SEND_BIND_RSP_NEG(BIND_RQ RCV_RECORD) (page 4-59). 


Call BUILD_AND_SEND_BINDF_RQ(SETUP_REJECT_AT_SLU, LULU_CB, sense data from 
the BIND response) (page 4-60). 

Determine the error type by examining the sense code in the BIND response 
(see Note in prologue). 

Call BUILD_AND_SEND_ACT_SESS RSP_NEG(LULU_CB.CORRELATOR, error type) 
(page 4-56). 

Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Call BUILD_AND_SEND, SESS DEACTIVATED(LULU_CB.LU_LU.HS_ ID, ABNORMAL_RETRY) 
(page 4-67). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Call BUILD_AND_SEND_UNBIND_RSP(UNBIND_RQ RCV_RECORD) (page 4-70). 
Determine the error type by examining the Type field in the UNBIND request. 
If it is invalid session parameters, or LU failure unrecoverable, 
or format or protocol error, the error type is NO_RETRY. 
For all other UNBIND types, the error type is RETRY. 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, error type) 
(page 4-56). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Call BUILD_AND_SEND_CINIT_RSP(HS_RCV_RECORD) (page 4-61) to send -RSP(CINIT). 
Determine the error type by examining LOCAL.SENSE_CODE (see Note in prologue). 
Call BUILD_AND_SEND_ACT_SESS RSP_NEG(LULU_CB.CORRELATOR, error tyne) 

(page 4-56). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


me 


Call BUILD_AND_SEND_SESS_ DEACTIVATED( LULU_CB.LU_LU.HS_ID, ABNORMAL_RETRY ) 
(page 4-67). 

Call BUILD_AND_SEND_UNBIND_RQ«LULU_CB, CLEANUP, X'00000000') (page 4-69). 

Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


If LOCAL.SENSE_CODE = X'00000000' then 
Set LOCAL.SENSE_CODE to PC_CONNECT_RSP.SENSE_CODE. 
Call BUILD_AND_SEND_BINDF_RQ(SETUP_REJECT_AT_PLU, LULU_CB, LOCAL.SENSE_CODE) 
(page 4-60). 
Determine the error type by examining LOCAL.SENSE_CODE (see Note in prologue). 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG(LULU_CB.CORRELATOR, error type) 
(page 4-56). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


If LOCAL.SENSE_CODE = X'00000000' then 
Set LOCAL.SENSE_CODE to PC_CONNECT_RSP.SENSE_CODE. 
Call BUILD_AND_SEND_BINDF_RQ(SETUP_REJECT_AT_PLU, LULU_CB, LOCAL.SENSE_CODE) 
(page 4-60). 
Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). 


Determine the error type by examining LOCAL.SENSE_CODE (see Note in prologue). 
Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, error type) 
(page 4-56). 
Call BUILD_AND_SEND_BINDF_RQ(SETUP_REJECT_AT_SLU, LULU_CB, LOCAL.SENSE_CODE) 
(page 4-60). 
Call CLEANUP_LU_LU_SESSION( LULU_CB) (page 4-72). 
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FSM_STATUS 


Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, RETRY) 
(page 4-56). 
| Call BUILD_AND_SEND_UNBIND_RQ(LULU_CB;, NORMAL, X'00000000') (page 4-69). 


pea Call BUILD_AND_SEND_UNBIND_RQ(LULU_CB, NORMAL, X'00000000') (page 4-69). 


Call BUILD_AND_SEND_DEACTIVATE_SESS( LULU_CB.LU_LU.HS_ID) (page 4-62). 


Call BUILD_AND_SEND_UNBIND_RQ( LULU_CB, NORMAL, X'00000000') (page 4-69). 
Call BUILD_AND_SEND_SESS_DEACTIVATED( LULU_CB.LU_LU.HS_ID, ABNORMAL_RETRY ) 
(page 4-67). 3 | | 


prologue)) (page 4-56). 


| TT Call BUILD_AND_SEND_BIND_RSP_NEG(BIND_R@Q_RCV_RECORD) (page 4-59). 
, Call BUILD_AND_SEND_ACT_SESS_RSP_NEG( LULU_CB.CORRELATOR, error type (see Note in 
‘Call CLEANUP_LU_LU_SESSION(LULU_CB) (page 4-72). | 


Call BUILD_AND_SEND_BINDF_RQ(SETUP_REJECT_AT_SLU, LULU_CB, sense data 
from the BIND response) (page 4-60). 


Call CLEANUP_LU_LU_SESSION( LULU_CB) (page 4-72). 
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LOCAL DATA STRUCTURES 


LOCAL 


LOCAL (this control block is accessible by any procedure in LNS) 
CPLU_CB_LIST list of CP-LU half-session control blocks (page A-1) 
LULU_CB_LIST list of LU-LU half-session control blocks (page A-5) 


SENSE_CODE (this field is set with a sense data value whenever an error is found) 


ERROR_TYPE 


ERROR_TYPE: possible values: RETRY, NO_RETRY 


SESSION_TYPE 


SESSION_TYPE: possible values: FIRST_SPEAKER, BIDDER 


DEFTYPE 1 RESET _NORMAL STRUCTURE; 
2 * CHAR(¥)5 


DEFTYPE 1 RESET_SON STRUCTURE; 
2 * CHAR(%); 
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CHAPTER 5.0. OVERVIEW OF PRESENTATION SERVICES 


GENERAL DESCRIPTION 


Presentation services (PS) is the component 
of the LU with which transaction programs 
interact directly. Each execution instance 
of a transaction program at the LU is served 
by its own PS process. This PS process is 
responsible for processing the transaction 
program's requests for LU services. The 
transaction program requests these services 
by issuing verbs. 


The verbs, along with their supplied and 
returned parameters, are fully described in 
SNA Transaction Programmer's Reference Manual 
for LU Type 6.2, which defines both the serv- 
ices that the LU provides and a syntax for 
transaction program requests for those serv- 
ices. The basic services are SNA-defined and 
are provided by all LU implementations, but 
the syntax of requests for the services may 
be implementation-defined. 


The services requested by verbs usually 
involve communication over a conversation 
with a transaction program at a remote LU. 
The supplied parameters of a verb therefore 
usually include an identifier of the conver- 
sation on which the verb is being issued. 
The data exchanged by conversing transaction 
programs is carried on a session assigned to 
the conversation. 


PS interacts with various other LU compo- 
nents. The LU resources manager (RM) creates 
and destroys the PS process, and assigns 
half-sessions to it for conversation traffic. 
PS exchanges data with these half-sessions in 
carrying out transaction program verb 
requests. PS also interacts with the trans- 
action program; or, more precisely, the PS 
process contains, and 1s driven by» a trans- 
action program execution instance (TP). 


PS COMPONENT FUNCTIONS 


Figure 5.0-1 on page 5.0-2 shows the compo- 
nents of PS. PS.INITIALIZE loads and calls 
the TP. The TP then issues verbs, which are 
processed by the other PS components. The TP 
ends by returning to PS.INITIALIZE. The 
functions and interactions of the PS compo- 
nents are further described below. 


TP: 


® Interacts directly with local end users 
and resources. 
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® Requests LU services (for interaction 
with remote resources) by issuing verbs. 


PS .INITIALIZE: 


® Receives program initialization parame- 
ters (PIP data). 

° Loads and calls the TP. 

e Instructs RM (after the TP completes and 
returns) to destroy this PS process. 


PS. VERB_ROUTER: 


® Checks every verb for compatibility with 
the type of the conversation on which it 
was issued, 

® Routes valid verb-issuances to the appro- 
priate’ verb-processing component. 


PS.MC, PS.SPS» ...» PS.COPR: 


®¢ Process non-basic verbs that request 
optional special services (these compo- 
nents and their associated services are 
described in separate chapters of this 


book). 

e Translate non-basic verbs into basic 
verbs. 

PS .CONV: 


e Processes basic conversation verbs. 

@e Checks each basic conversation verb for 
compatibility with the state of the con- 
versation on which it was issued. 

° Performs (in co-operation with or at the 
request of other verb-processing compo- 
nents) all basic conversation services. 


All the components of the PS process (includ- 
ing the transaction program execution 
Instance ) interact synchronously (using 
call/return logic). PS may exchange informa- 
tion with other LU components by means of 
asynchronous inter-process communication (us- 
ing send/receive logic). 


DATA BASE STRUCTURE 


PS uses several data structures to record 
information needed to provide services to the 
transaction program. These data structures 
include PS_PROCESS_DATA, the transaction con- 
trol block (TCB), and the resource control 
block list (RCB_LIST). This chapter 
describes the use of these data structures 
by the PS.INITIALIZE and PS.VERB_ROUTER com- 
ponents. Use of data structures by other PS 
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"Chapter 5.1. Presentation Services--Conversation Verbs" 
"Chapter 5.2. Presentation Services--Mapped Conversation Verbs" 
"Chapter 5.3. Presentation Services--Syne Point Services Verbs" 
"Chapter 5.4. Presentation Services--Control-Operator Verbs" 


A dashed line denotes a synchronous (i.e., a CALL) protocol boundary between components, 
while a solid line denotes an asynchronous (j3.e., a SEND) protocol boundary. 


5.0-1. Overview of Presentation Services, Emphasizing PS.INITIALIZE and PS.VERB_ROUTER 


5.0-2 


components is described in detail in the cor- 
responding chapters. 


PS _PROCESS_DATA on page 5.0-19 contains data 
that is accessible by all components of the 
PS process. This data includes pointers to 


lists of shared control blocks, and to single 
control blocks describing the local LU and 
this PS process. These pointers are initial- 
ized with data passed from RM when it creates 
the PS process, and they remain unchanged 
thereafter. 
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Half- Resources 
Session Manager PS INITIALIZE 
create PS process 
CL eee > 
ATTACH_RECEIVED 
(2) > 
RECEIVE_DATA 
(3) 
(4) iad eae vane 
(5) oe 
DEALLOCATE_RCB 
< 
RCB_DEALLOCATED 
> 
TERMINATE_PS 
(6) < 
destroy PS process 
ee re > 
Figure 5.0-2. 


Transaction 
Program 


> I only if PIP data present 


CALL FPCRCB_ID, PIP1, ...» PIPn) 


The transaction control block (TCB, page 
A-10) contains information specific to the 
transaction program instance, such as the 
list of resources allocated to it, the secu- 
rity user ID ("Appendix H. FM Header and LU 
Services Commands") carried in the Attach, 
and the security profile ("Appendix H. FM 
Header and LU Services Commands") optionally 
carried in the Attach. The TCB also contains 
the CONTROLLING _COMPONENT field, which is 
maintained by PS.VERB_ROUTER, and records 
whether the verb was issued by the TP or by a 
verb-processing component (on behalf of the 
TP). The TCB is created by RM when the PS 
process 15 created and destroyed by RM when 
the PS process is destroyed. 


The resource control block (RCB, page A-7) 
contains information specific to a particular 
resource, such as the state of a conversation 
or the conversation type. One RCB exists for 
each active resource (e.g., for each active 
conversation). The RCB is created = and 
destroyed by RM at the request of PS as part 
of the processing of the ALLOCATE and DEALLO- 
CATE verbs. Certain fields of the RCB are 
shared between PS and RM, while other fields 
are used exclusively by PS. 
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zero or more times 


Initialization and Termination of Presentation Services and Transaction Program 


INITIALIZATION AND TERMINATION 
(PS.INITIALIZE ) 


The PS.INITIALIZE component performs initial- 
ization and termination of PS and the TP. 


Figure 5.0-2 shows the protocol boundary 
flows that are used by PS.INITIALIZE for 
initialization and termination of the PS 
process. The steps below correspond to the 
numbers in the figure. 


1. The PS process is created by RM; which 
passes it several parameters, including 
the LUCB_LIST_PTR, the TCB_LIST_PTR and 
the RCB_LIST_PTR. These parameters are 
used to initialize the PS_PROCESS_DATA 
structure. 


2. PS next receives from RM an FMH-5 (At- 
tach), accompanied by the TCB ID of this 
instance of PS, the RCB ID of the initial 
conversation (the conversation on which 
the Attach flowed), and sense data con- 
taining the result of RM's checking of 
the Attach. If the sense data is 0 (in- 
dicating no error was found by RM), 
PS.INITIALIZE performs additional check- 
ing of the Attach. This includes a check 
of the transaction program's support of 
the conversation type and program 


Overview of Presentation Services 5.0~3 


5.0-4 


initialization parameters (PIP data). If 
the Attach is in error (as determined by 
RM or PS.INITIALIZE) the conversation is 
terminated. Depending on the error 
detected, the session may be deactivated, 
or the conversation ended with DEALLOCATE 
TYPE(ABEND_PROG). 


3. The Attach indicates whether PIP data 
follows. If the Attach is correct, the 
PIP data (if any) is received as a single 
GDS variable, and is then separated into 
a list of individual PIP subfields. 


4. An execution instance of the transaction 
program named in the Attach is then cre- 


ated. This TP is called with arguments. 
ofthe RCB ID of the initial conversation | 


Send the list of PIP subfields (if pres- 
ent). 


5. When the TP completes 
(normally or abnormally), it returns to 
PS.INITIALIZE. PS.INITIALIZE terminates 
and deallocates Cin an 
implementation-dependent way) the TP's 
remaining active conversations (if any; 
the list of conversations that are still 
active is found in the RESOURCES_LIST of 
the TCB). 


6. Finally. ©y.INITIALIZE sends a TERMI- 
N&Te_PS record to the resources manager 
and ‘waits to be terminated. On receipt 
of the TERMINATE_PS record, RM destroys 

~ the PS process. 


VERB PROCESSING (PS.VERB_ROUTER) 


PS.VERB_ROUTER routes verbs to the appropri- 
ate PS verb-processing component. It also 
processes type-independent conversation verbs 
such as WAIT and GET_TYPE. The supplied 


has been issued. directly by the TP. 


- processing» 


RESOURCE parameter of most verbs identifies 
the conversation on which the verb is being 
issued. The value in the RESOURCE parameter 
must match one in TCB.RESOURCES_LIST, the 
list of resources allocated to the TP; if it 
does not, the TP is terminated abnormally. 


PS.VERB_ROUTER also maintains the CONTROL- 
LING_COMPONENT field of the TCB. The value 
of CONTROLLING_COMPONENT is TP if the verb 
The val- 
ue is SERVICE_COMPONENT if the verb has been 
issued by another PS component as Part of its 


verb processing. 


_, WAIT Verb Processing 


The WAIT verb is not processed by PS.CONV, 


because (unlike most verbs) it is not issued 


over a conversation. Instead, it allows a TP 
to wait until specified conditions are satis- 
fied ("“posted'') for any of several conversa- 


tions. WAIT processing includes: 


® Checking that al] the resovrce IDs are 
valid and that at least one resource is 
activated for posting 

® Determining whether a resource is already 
posted (and, if one is», returning imme- 
diately) 


® Awaiting, if no posting condition has 
been satisfied, the arrival of data that 
will cause a resource to be posted 


GET TYPE Verb Processing _ 


GET_TYPE processing is. handled locally in 
PS.VERB_ROUTER by copying the conversation 
type from the appropriate RCB into a returned 
parameter of the verb. 
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HIGH-LEVEL PROCEDURES 


PS 


FUNCTION: 


OUTPUT : 


Presentation services (PS) provides verb-processing services to a transaction 
program execution instance (TP). PS invokes, terminates, contains, and is 
driven by the TP. 


LUCB_LIST_PTR, TCB_LIST_PTR, and RCB_LIST_PTR, pointers to  LUCB_LIST, 
TCB_LIST, and RCB_LIST, respectively; LU_ID, the ID of this LU; and TCB_ID, 
the ID of this PS process 


Process data 1s initialized and PS.INITIALIZE is invoked. 


Referenced procedures, FSMs, and data structures: 


PS_ INITIALIZE page 5.0-6 
PS_PROCESS_DATA page 5.0-19 
TCB page A-10 
LUCB page A-l 
LUCB_LIST_PTR page 5.0-20 
RCB_LIST_PTR page 5.0-20 
TCB_LIST_PTR page 5.0-20 
LU_ID page 5.0-20 
TCB_ID page 3-74 


Copy the input parameters into the fields of PS_PROCESS_DATA (page 5.0-19). 

Set PS_PROCESS_DATA.LUCB_PTR to point to the LUCB for this LU (identified by LU_ID). 

Set PS_PROCESS_DATA.TCB_PTR to point to the TCB for this transaction process 
(identified by TCB_ID). 


Call PS. INITIALIZE (page 5.9-45). 
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PS INITIALIZE 


5.0-6 


PS_INITIALIZE 


FUNCTION: 


INPUT: 


OUTPUT : 


This procedure creates and invokes an 
named in a received FMH-5 (Attach). 


instance of the transaction program 


After PS is created by RM, PS.INITIALIZE receives the Attach and other infor- 
mation from RM. As shown in "'FM header 5: Attach " on page H-6, the Attach 
contains the name of the transaction program to be invoked, and an indicator 
of whether program initialization parameters (PIP data) will accompany the 
Attach. PS.INITIALIZE receives the PIP data (if any) from the half-session, 
and validates fields of the Attach. 


If the Attach is valid, PS invokes the transaction program named in the 
Attach. When the TP returns to PS.INITIALIZE, the PS process is destroyed (by 
calling DEALLOCATION_CLEANUP_PROC). 


If the Attach contains an error, ATTACH_ERROR_PROC 


is called and the PS proc- 
ess is destroyed; no transaction program is invoked. | 


Attach information (from RM) 
An execution instance of a transaction program is loaded and called. The TP 
is passed the RCB_ID representing the conversation between the attached pro- 


gram and the attaching program, and PIP data, if there is any. 


Rather than invoking the transaction program immediately upon receipt of the 
Attach,» PS may await the receipt of data elas end-of-chain before dis- 


patching the transaction program. 


Referenced procedures, FSMs, and data structures: 


INITIALIZE_ATTACHED_RCB page 5.0-16 
RECEIVE _PIP_FIELD_FROM_HS page 5.0-7 
PS_ATTACH_CHECK page 5.0-8 
UPM_EXECUTE page 5.0-17 
ATTACH_ERROR_PROC page 5.0-10 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
PS_PROCESS_DATA page 5.0-19 
TCB page A-10 
RCB page A-7 
PIP_FIELD page 5.0-19 
PIP_LIST page 5.0-20 
CODE, see SENSE_DATA page 5.0-21 


Receive Attach information from RM. 

Find the RCB for the conversation identified by RCB_ID. 

Call INITIALIZE_ATTACHED_RCB( ATTACH_RECEIVED) (page 5.0- 16). 

Call RCB. FSM_CONVERSATION(R, ATTACH, RCB) (page 5.1-63). 

Copy into the TCB the transaction program name, profile, and user ID fields 
of the Attach with trailing blanks removed. 


Set TCB.CONTROLLING_COMPONENT to TP. 


If Attach check CODE frne RM indicates Attach is valid then 
If the Attac* (see page H-6 for format) indicates 
th=* -iP data is present, then 
Call RECEIVE_PIP_FIELD_FROM_HS(RCB,PIP_FIELD) (page 5.0-7). 
Else 
Set PIP_FIELD to null. 
Call PS_ATTACH_CHECK (page 5.0-8)., 
and pass it PIP_FIELD and relevant Attach information. 
Store the resulting sense data in CODE. 
If the Attach is valid (CODE=0) then 
Call UPM_EXECUTE(TCB. TRANSACTION_PROGRAM_NAME, RCB.RCB_ID, PIP_LIST) 
(page 5.0-17) (see Note). 
Else (Attach is not valid) 
Call ATTACH_ERROR_PROC(RCB, CODE) (page 5.0-10). 


Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
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RECEIVE_PIP_FIELD_FROM_HS 


RECEIVE_PIP_FIELD_FROM_HS 


FUNCTION: During invocation of the transaction program, this procedure receives a pro- 
gram initialization parameter (PIP) field by issuing a RECEIVE_AND_WAIT verb. 
If this verb-issuance succeeds in receiving a complete logical record contain- 
ing a PIP Data GDS variable, then the received PIP field is returned to 
PS.INITIALIZE. If it fails, a protocol violation has been committed by the 
partner LU; the session is deactivated and the transaction program is not 
invoked. 


INPUT: The RCB for the TP's initial conversation; a PIP Data GDS variable from the 
half-session 


OUTPUT : A RECEIVE_AND_WAIT verb jis issued in order to retrieve the expected PIP data, 
which 1s returned to PS.INITIALIZE via PIP_FIELD. 


NOTES: 1. The RECEIVE_AND_WAIT structure that is created in this procedure cannot be 
destroyed at only the end of the procedure. The reason for this is that if a 
protocol violation is detected and DEALLOCATION_CLEANUP_PROC is invoked, this 
process ends without ever returning to this procedure. (In this case, the 
RECEIVE_AND_WAIT would never be destroyed. ) 


2. This error occurs if the partner indicates in the Attach that PIP data fol- 
lows, but either no data follows or the data that follows 1s not PIP data. 


Referenced procedures, FSMs, and data structures: 


PS _PROTOCOL_ERROR page 5.0-15 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
PS _PROCESS_DATA page 5.0-19 
RCB page A-7 

PIP_FIELD page 5.0-19 


Issue a RECEIVE_AND_WAIT verb on this conversation, with 
a MAX_LENGTH of X'7FFF', a FILL of LL, and a DATA parameter of PIP_FIELD. 
If PIP_FIELD does not now contain 
a complete PIP Data GDS variable (see page H-7 for format), 
then (optional receive check—see Note 2) 
Call PS_PROTOCOL_ERROR(RCB.HS_ID, RCB.RCB_ID, X'1008201D') (page 5.0-15). 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) 
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PS_ATTACH_CHECK 


5.0-8 


PS_ATTACH_CHECK 


FUNCTION: 


INPUT: 


OUTPUT: 


NOTE : 


This procedure validates some fields of the received Attach (RM validates the 
other fields). 


Attach information (from RM) and program initialization parameter (PIP) data 
from HS. “4 | 


0, 1f no invalid fields are found; the appropriate sense data, otherwise 


If RM finds 


the Attach 


invalid, it is accompanied by sense data 


SENSE_CODE) with one of the following values: 


X'O80F6051' 
X'10086000' 
X'10086005' 
X'10086009' 
X'1008600B' 
X'10086011' 
X'10086021' 
X'10086040' 
X'084B6031' 
X'084C0000' 
X'10086040' 
X'10086041' 


Security not valid 

FMH length not correct 

Access Security Information field length invalid 
Invalid parameter length | | 
Unrecognized FMH command 

LUN length invalid 

TPN not recognized 

Invalid Attach parameter 

Transaction program not available—retry 
Transaction program not available—no retry 

Sync level not supported by LU 

Syne level not supported by TP 


Otherwise, SENSE_CODE = X'00000000'. 


Referenced procedures, FSMs, and data structures: 
PS_PROCESS DATA 


page 5.0-19 


TCB page A-10 
LUCB page A-l 
TRANSACTION_PROGRAM page A-4 
PIP_FIELD page 5.0-19 


SENSE_CODE, see SENSE_DATA 


page 5.0-2]1 
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PS_ATTACH_CHECK 


If SENSE_CODE > 0, then 
Return sense data set by RM. 

Else (continue seeking Attach errors) 
Set TRANSACTION_PROGRAM to the LUCB.TRANSACTION_PROGRAM_LIST-element 
named in Attach. 


Select, in order, based on 
the contents of the Attach (for format, see page H-6): 


Errors that cause the session to be deactivated 


When the Logical Unit of Work Identifier fields are incorrectly formatted 
Return X'10086011'. 


Errors that cause an FMH-7 to be generated 


When TRANSACTION PROGRAM.NUMBER_OF_PIP_SUBFIELDS=0, 
but the Attach indicates that PIP data is present 
Return X‘'10086031' (PIP not allowed). 


When TRANSACTION_PROGRAM.NUMBER_OF_PIP_SUBFIELDS is positive, but 
the actual number of PIP subfields (in PIP_FIELD) differs from it, 
or PIP data is not indicated as present 

Return X'10086032' (PIP not specified correctly). 


When the Resource type is not supported by the transaction program 
(i.e.5 15 not on the TRANSACTION_PROGRAM.RESOURCES_SUPPORTED_LIST) 
Return X'10086034¢' (conversation type mismatch). 


Otherwise (ATTACH is valid) 
Return X‘'00000000'. 
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ATTACH_ERROR_PROC 
ATTACH_ERROR_PROC 


This procedure handles the processing required when an invalid FMH-5 (Attach) 
is received. 


Depending upon the type of Attach error (as reflected in tie pesaes SENSE_CODE 
parameter), PS either generates an (FMH-7,CEB) or causes the session over 
which the Attach flowed to be deactivated. 


When the Attach contains an error that violates defined protocols, PS requests 
that the session be deactivated. 


For all other Attach errors, PS first issues a SEND_ERROR record to the 


half-session. PS then creates an FMH-7 error message that contains sense 
data identifying the type of Attach error encountered. PS also sends DEALLO- 
CATE_RCB to RM, and then instructs RM to terminate the PS process. 


The RCB corresponding to the conversation over which the invalid Attach nas 
received, and sense data specifying the type of Attach error are received as 
parameters. 


The session is deactivated or an FMH-7 error message is sent to the 
half-session and the conversation is ended. (Error data is optionally logged 
and sent with the FMH-7. ) 


Referenced procedures, FSMs, and data structures: 


PS_PROTOCOL_ERROR page 5.0-15 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
GET_END_CHAIN_FROM_HS page 5.1-37 
SEND_ERROR_TO_HS_PROC page 5.1-56 
UPM_ATTACH_LOG page 5.0-18 
SEND_DATA_BUFFER_MANAGEMENT ee page 5.1-51 
SEND_DATA_TO_HS_PROC page 5.1-52 
PS_PROCESS_ DATA page §.0-19 
RCB page A-7 
BUFFER_ELEMENT page A-8 
SENSE_CODE, see SENSE_DATA page 5.0-21 


If SENSE_CODE is 
X'1008200E', X‘'10086000', X°'10086005', X*'10086009', X'10086011', or "10086040", 
then (deactivate the session) | 
Call PS_PROTOCOL_ERROR(RCB.HS_ID, RCB.RCB_ID, SENSE_CODE) (page 5.0-15). 
Call DEALLOCATION CLEANUP _ PROC (page 5.0-13). 
Else (generate an FMH-7) 
Call SEND_ERROR_TO_HS_PROC(RCB) (page 5.1-56). 
Call GET_END_CHAIN FROM_HS(RCB) (page 5.1-37). 
Set BUFFER_ELEMENT to the last entry in RCB.HS_TO_PS_BUFFER_LIST. 
If the BUFFER_ELEMENT type is 
DEALLOCATE_CONFIRM, CONFIRM, PREPARE_TO_RCV_CONFIRM, or PREPARE_TO_RCV_FLUSH 
then 
Call UPM_ATTACH_LOG (page 5.0-18) to 
generate log data describing this Attach error. 
If this log data is non-null, then 
Log it in the local system error log 
Put into the conversation's send buffer (RCB.PS_TO_HS_RECORD .DATA) 
an FMH-7 (page H-8) indicating that 
log data follows and sense data (from SENSE CODE) is included. 
Append to the conversation's send buffer an 
Error Log GOS variable (page H-19) containing the log data. 
Else 
Put into the conversation's send buffer (RCB.PS_TO_HS_RECORD .DATA) 
an FMH-7 (page H-8) indicating that 
no log data follows and sense data (from SENSE CODE) is included. 
Call SEND_DATA_BUFFER_MANAGEMENT( null string, RCB ) (page 5.1-51). 
Set RCB.PS_TO_HS_RECORD.TYPE to DEALLOCATE FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
Send a DEALLOCATE_RCB record (page A-26), derived from this RCB, to RM. 
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PS _VERB_ROUTER 


FUNCTION: 


INPUT : 


OUTPUT: 


NOTES: 1. 


PS_VERB_ROUTER 


This procedure receives all verbs issued by the TP and routes them to the 
appropriate PS component (e.g., basic conversation verbs to PS.CONV, and 
control-operator verbs to PS.COPR) for processing. 


The current transaction program verb. 


Refer to the PS components that are called from this process for the specific 
outputs. 


As a general rule, basic verbs must be issued on basic conversations. This 
check enforces that rule; however, there are some exceptions. Non-basic 
verb-processing components reside above PS.CONV, and may issue basic conversa- 


tion verbs in carrying out the functions of non-basic verbs. When the TP 
issues a mapped conversation verb, PS.VERB_ROUTER routes the verb to PS.MC. 
PS.MC begins processing the verb, and then, 1n general, issues one or more 
basic conversation verbs, which are processed by PS.CONV. Thus, PS.MC may 
issue a basic conversation verb on a mapped conversation. PS.MC is allowed to 
do this because it is a "service'’ component that is part of PS; the trans- 
action proyram is not. PS.VERB_ROUTER maintains Knowledge, via the CONTROL- 
LING COMPONENT field in the TCB, of whether the verb currently being processed 
was issued by the transaction program or by a service component such as PS.MC. 


If the TP issues a verb that is incompatible with the specified resource, such 
as a mapped conversation verb specifying a basic conversation, then the TP has 
committed a protocol violation and is terminated abnormally. 


Referenced procedures, FSMs» and data structures: 


PS_ CONV page 5.1-10 
DEALLOCATION_CLEANUP_ PROC page 5.0-13 
WAIT_PROC page 5.0-13 
PS_ MC page 5.2-19 
PS_COPR page 5.4-32 
PS_ SPS page 5.3-35 
PS_ PROCESS DATA page 5.0-19 
TCB page A-10 

RCB page A-7 


Select based on TRANSACTION_PGM_VERB contents 


Verbs Processed by Presentation Services for Conversations 


When ALLOCATE 
Call PS_CONV( verb,parameters ) (page 5.1-10). 
l When CONFIRM, CONFIRMED, DEALLOCATE, FLUSH, GET_ATTRIBUTES, POST_ON_RECEIPT, 
| PREPARE_TO_RECEIVE, RECEIVE_AND_WAIT, RECEIVE_IMMEDIATE, REQUEST_TO_SEND; 
| SEND_DATA, SEND_ERROR, or TEST 
If the supplied RESOURCE parameter of the verb 
fails to identify a conversation assigned to this transaction 
(i.e., does not occur on on TCB.RESOURCES_LIST), then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
Find the RCB for the conversation identified by the supplied RESOURCE parameter. 
If RCB.CONVERSATION_TYPE“BASIC_CONVERSATION and 
TCB.CONTROLLING_COMPONENT#SERVICE_ COMPONENT 
then (see Note 1) 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
Call PS_CONV(verb,parameters) (page 5.1-10). 
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PS_VERB_ROUTER 


Verbs Processed by Presentation Services for Mapped Conversations 


When MC_ALLOCATE 
Call PS MC verb parameters ) (page 5.2-19). 

When MC _CONFIRM, MC_CONFIRMED, MC_DEALLOCATE, MC FLUSH, NC_GET _ATTRIBUTES, 
a POST_ ON_RECEIPT, MC_PREPARE _T0 RECEIVE, MC _RECEIVE_ AND_WAIT, 
MC_ REQUEST _ TO_SEND, MC_SEND _DATA; MC_SEND_ ERROR, or MC_ TEST 

If the verb's supplied RESOURCE parameter 
fails to identify a conversation assigned to this transaction 
(i.e., fails to occur on TCB.RESOURCES_LIST), then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
- Find the RCB for the. conversation identified by RESOURCE. 
If RCB.CONVERSATION_TYPE is not MAPPED CONVERSATION, 
then Cit should be, because this verb is wapped } 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
Set TCB.CONTROLLING_| COMPONENT to SERVICE_COMPONENT. 
Call PS _MC( verb, parameters ) (page 52-19). 
Set TCB.CONTROLLING_COMPONENT back to TP. 


Verbs Processed by Presentation Services for the Control Operator 


When INITIALIZE _SESSION_LIMIT, CHANGE_SESSION_LIMIT, RESET_ SESSION_LINIT, 
SET_LUCB, SET_ PARTNER_ tu, SEY_MODE, 
SET_MODE _OPTION, SET, TRANSACTION PROGRAM, SET. PRIVILEGED_FUNCTION, 
SET_RESOURCE _ SUPPORTED» SET_SYNC_LEVEL_SUPPORTED, 
SET_MC_FUNCTION SUPPORTED_TP, SET_ CPLU_ CAPABILITY, 
GET LUCB, GET_ PARTNER_ LU, GET _MODE ; GET_LU_OPTION, GET_MODE_OPTION, 
GET. TRANSACTION PROGRAM, GET_ PRIVILEGED _ FUNCTION, GET_. RESOURCE_ SUPPORTED» 
GET_SYNC _LEVEL_ SUPPORTED» GET_ MC FUNCTION SUPPORTED_LU, 
GET_MC_ FUNCTION _SUPPORTED_TP, GET_ CPLU | CAPABILITY, 
LIST_PARTNER_LU, LIST_MODE, LIST_LU_OPTION, LIST_MODE_OPTION, 
LIST_TRANSACTION_ PROGRAM, LIST _PRIVILEGED_FUNCTION, LIST_RESOURCE_SUPPORTED, 
LIST_SYNC_LEVEL_ SUPPORTED, LIST _MC_FUNCTION _SUPPORTED_LU, 
LIST_MC_FUNCTION_SUPPORTED_TP, LIST_CPLU_CAPABILITY; 
PROCESS _SESSION_LIMIT, ACTIVATE _SESSION, or DEACTIVATE_SESSION 
Set TCB.CONTROLLING_ COMPONENT to SERVICE COMPONENT; 
Call PS_COPR( verb parameters) (page 5.4-32), and 
Set TCB.CONTROLLING COMPONENT back to TP... 


“‘Type-Independent Conversation Verbs 


When SYNCPT or BACKOUT 
Set TCB.CONTROLLING_COMPONENT to SERVICE _COMPONENT; 
Call PS_SPS (page 5.3-35), 
Set TCB. CONTROLLING COMPONENT back to TP. 


When GET_TYPE 
If the verb's supplied RESOURCE parameter 
fails to identify a conversation assigned to this transaction, then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
Find the RCB for the conversation identified by RESOURCE. 
Copy RCB.CONVERSATION_TYPE into the verb! s returned TYPE cueerees 


When WAIT 
Set TCB.CONTROLLING_ COMPONENT to SERVICE COMPONENT, 
Call WAIT _PROC( verb, parameters ) ‘(page &.0-13),. 
Set TCB.CONTROLLING COMPONENT back to TP. 


RETURN; 


5.0-12 SNA Format and Protocol Reference Manual for LU Type 6.2 


DEALLOCATION_CLEANUP_ PROC 
DEALLOCATION_CLEANUP_PROC 


This procedure, which manages the destruction of this process, is invoked 
after the TP has ended (normally or abnormally) by returning to PS_INITIALIZE 
on page 5.0-6. It calls UPM_RETURN_PROCESSING on page 5.0-18 to deallocate 
the process's remaining conversations, and sends DEALLOCATE_RCB to RM to get 


rid of RCBs and any other resources allocated to the process. Finally, it 
instructs RM (by sending a TERMINATE_PS record) to destroy the process. 


TCB.RESOURCES LIST 


DEALLOCATE_RCB and TERMINATE_PS to RM. 


Referenced procedures, FSMs, and data structures: 


UPM_RETURN_PROCESSING page 5.0-18 
PS_PROCESS DATA page 5.0-19 
TCB page A-10 
RCB page A-7 
TERMINATE_PS page A-27 
RCB_ID page 3-74 


For each RCB_ID on TCB.RESOURCES LIST, do the following: 
Find the RCB for the conversation identified by RCB_ID. 
If the conversation is not already in RESET or END_CONV state, then 
Call UPM_RETURN_PROCESSING(RESOURCE.RCB_ID) (page 5.0-18). 
Send a DEALLOCATE_RCB record (page A-26), derived from this RCB, to RM. 


Send a TERMINATE_PS record to RM. 
Wait to be destroyed by RM. 


WAXT_PROC 


This procedure processes WAIT verbs. First, it validates the resources speci- 
fied in the verb'’s RESOURCE_LIST parameter. tbthile checking this List, this 
procedure creates a sublist of it called TEMPORARY _RESOURCE_LIST. This sub- 
list contains only those resources from RESOURCE_LIST that are currently acti- 
vated for posting. (If none of the resources specified in the supplied 
RESOURCE_LIST parameter is activated for posting, this procedure sets the 
RETURN_CODE field of the WAIT to POSTING_NOT_ACTIVE.) 


After creating the TEMPORARY _RESOURCE_LIST, this procedure next checks to see 
if any of the resources in the list have already been posted. If none of the 
resources has been posted, this procedure waits for one of the resources to 
become posted. 


WAIT verb parameters; incoming conversation data 


The verb's returned parameters are set as follows. RETURN_CODE indicates 
whether the WAIT completed successfully. (Any return code other than POST- 
ING_NOT_ACTIVE indicates that a resource was posted and the WAIT completed 
successfully.) If the verb completed successfully, then RESOURCE POSTED indi- 
cates which resource has been posted. 


Referenced procedures, FSMs,» and data structures: 


TEST_FOR_RESOURCE_POSTED page 5.0-17 
DEALLOCATION_CLEANUP_ PROC page 5.0-13 
PS_PROCESS DATA page 5.0-19 
TCB page A-10 
RCB page A-7 
RC, see RETURN_CODE page 5.0-19 
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WAIT_PROC 


Check that all resources in the sipiied RESOURCE_ LIST parameter 
are validly allocated to this transaction (i.e., occur in TCB. RESOURCES_ LIST), 
and that at least one of them has posting active. 
If any resource is invalid, then | 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
If no resource has been posted, then | 
Set the verb's primary RETURN_CODE to POSTING_ NOT ACTIVE, and return. 


At this point (since all resources are valid and some have "posting 


active'), it is safe to wait for a resource to become posted. If some 
resource is already posted, though, then there is no need to wait. 


For each resource that has posting active, . 
Call TEST_FOR_RESOURCE_POSTED (page 5.0-17) 
on its RCB, and save the result in RC. 
If RC is not UNSUCCESSFUL, then 
Set the verb's RETURN_CODE to RC, and return. 


| Since no active resource is posted yet, wait until one is. 


Initialize RC to UNSUCCESSFUL. 
Do While RC remains UNSUCCESSFUL 
Suspend this process until an HS for a posting-active resource forwards received 
data to that resource. 
Set RCB to the RCB for the conversation on which the data has arrived. 
Call TEST_FOR_RESOURCE_POSTED(RCB) (page 5.0-17--see Note 5 
; and save the result in RC. 
Set the returned RESOURCE_POSTED parameter to RCB.RCB_ID. 
Set the verb's RETURN_CODE to RC. 
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LOW-LEVEL PROCEDURES 


PS_PROTOCOL_ERROR 


FUNCTION: This procedure processes receive error conditions that require the session to 
be deactivated. 


An UNBIND_PROTOCOL_ERROR record is sent to the resources manager to request 
deactivation of the session that committed the protocol violation. Then the 
procedure creates a CONVERSATION_FAILURE (PROTOCOL_VIOLATION) record and con- 
tinues the conversation failure processing. 


The HS ID for the half-session that committed the protocol violation, the RCB 
ID for the conversation that is using the session, and the sense data to be 
sent on the UNBIND 


OUTPUT: UNBIND_PROTOCOL_ERROR (to RM), with the TCB ID for this PS process, and the 
input HS ID and sense data 


Referenced procedures, FSMs, and data structures: 


CONVERSATION_FAILURE_PROC page 5.1-31 
PS PROCESS DATA | page 5.0-19 
UNBIND_PROTCCOL_ERROR | page A-28 
CONVERSATION_FAILURE page A-32 
HS_ID page 3-74 
RCB_ID page 3-74 
SENSE_CODE, see SENSE_DATA page 5.0-21 


Create an UNBIND_PROTOCOL_ERROR record (page A-28) 
with this TCB_ID, HS_ID, and SENSE_CODE. 
Send UNBIND_PROTOCOL_ERROR to RM. 


Create a CONVERSATION_FAILURE record with RCB_ID for this conversation. 


Set its REASON to PROTOCOL_VIOLATION. 
Call CONVERSATION_FAILURE_PROC(CONVERSATION_FAILURE) (page 5.1-31). 
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INITIALIZE_ATTACHED_RCB 


INITIALIZE_ATTACHED_RCB 


FUNCTION: This procedure initializes fields in the RCB for the resource specified in the 
received Attach. 


This procedure is invoked by PS.INITIALIZE when RM forwards Attach information 
to PS. 


INPUT: Attach information (from RM) (see "FM header 5: Attach " on page H-6 for for- 
mat ) | 


OUTPUT: Fields in the specified RCB are initialized. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
PS_PROCESS_DATA page 5.0-19 
RCB page A-7 


Find the RCB identified in the received Attach. 
Initialize this RCB's fields as follows: 
PS_TO_HS_RECORD.ALLOCATE to NO 
PS TO_HS RECORD.FMH to NO 
PS TO_HS_RECORD.TYPE to NOT_END_OF_DATA 
PS_TO_HS_RECORD.DATA to null string 


SEND_LL_REMAINDER to 0 

RECEIVE _LL_REMAINDER to 0 

MAX_BUFFER_LENGTH to an implementation-defined maximum 
RQ_TO_SEND_RCVD to NO 

LOCKS to SHORT 

POST_CONDITIONS.FILL to LL 

POST_CONDITIONS.MAX_LENGTH to 0 

SEND_LL_BYTE to NOT_PRESENT 


SYNC_LEVEL to the synchronization level specified in the Attach 
CONVERSATION_TYPE to the Resource type specified in the Attach 


If RCB.CONVERSATION_TYPE = MAPPED_CONVERSATION then 
Initialize additional RCB fields as follows: 
MC_RQ_TO_SEND_RCVD to NO 
MC_POST to RESET 
MC_MAX_SEND_SIZE to an implementation-defined value 
MAPPER_SAVE_AREA according to an implementation-defined algorithm. 


\ 
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TEST_FOR_RESOURCE_POSTED 
TEST_FOR_RESOURCE_POSTED 


This procedure determines if the resource corresponding to the passed RCB has 
been posted. Depending on the type of conversation indicated by the RCB, this 
procedure calls either TEST_PROC on page 5.1-27 or MC_TEST_PROC on page 5.2-28 
to test whether the resource has been po 


The RCB for the resource whose posting status is to be determined 


The return code returned from the TEST_PROC or MC_TEST_PROC call. 


Referenced procedures, FSMs, and data structures: 


TEST_PROC page 5.1-27 
MC_TEST_PROC page 5.2-28 
PS_PROCESS_DATA page 5.0-19 
RCB page A-7 
RETURN_CODE page 5.0-19 
Select based on RCB.CONVERSATION_TYPE: 
When basic 
Call TEST_PROC(RCB, POSTED) (page 5.1-27). 
When mapped 


Call MC_TEST_PROC(RCB,POSTED) (page 5.2-28). 
Return the verb's RETURN_CODE. 


UNDEFINED PROTOCOL MACHINES 


UPM_EXECUTE 


This UPM loads and executes a transaction program. 


The name of the transaction program, the resource ID (to be passed to the 
transaction program), and a list of PIP data (to be passed to the transaction 
program). 


None. 


Not defined by SNA 
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UPH_ATTACH_LOG 
UPM_ATTACH_LOG 


This UPM is invoked upon discovery of an error in an FMH-5 (Attach). It 
returns log data describing the error. This data is logged in the local sys- 
tew error log and is sent back to the conversation partner in an Error-Log 60S 


variable accompanying an FMH-7. 


Attach error sense data 


Leg data (may be null) 


tc Not defined by SNA 


UPM_RETURN_PROCESSING 


This UPM is invoked when a TP ends and returns to PS without having deallo- 
cated all its resources. It terminates and deallocates a remaining active 
resource in an implementation-specific way. Two of the many ways in which an 
implementation could do this are to: 


® Issue DEALLOCATE TYPE(ABEND PROG) for the still-allocated resource. 


@e Issue DEALLOCATE TYPE(SYNC_LEVEL) if the resource is in SEND state and 
data in PS's send buffer is on a logical record boundary. If the attempt 
to synchronize fails, or the data was not on a logical record boundary, 
then issue DEALLOCATE TYPE( ABEND_PROG). 


Regardless of what other actions are taken, this UPM causes FSM_CONVERSATION 
(page 5.1-63) to enter the reset state. 


The RCB_ID of the still-allocated resource 
See above. 


| Not defined by SNA ) 
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LOCAL DATA STRUCTURES 


PS_PROCESS_DATA 


PS_PROCESS_DATA is available to all procedures in the presentation services process. The 
structure is initialized by the PS process (page 5.0-5) and remains unchanged for the 
lifetime of the PS process. 


PS_PROCESS_DATA 
LUCB_LIST_PTR: Pointer to the LUCB_LIST 


LU_ID: ID of this PS's LU 

LUCB_PTR: Pointer to the LUCB foi: this PS's LU 
TCB_LIST_PTR: Pointer to th: fCB_LIST 

TCB_ID: ID of this PS 

TCB_ PTS: Pointer to the TCB for this PS 


«CB_LIST_PTR: Pointer to the RCB_LIST of this PS 


PIP_FIELD 


Program Initialization Parameter (PIP) data is sent as a GDS variable immediately follow- 
ing the FMH-5 if the FMH-5 indicated that PIP data follows. 


NOTES: 1. The value in the LL field includes the length of the LL field itself. 


2. PIP subfields are type G symbol strings. Minimum send and receive support for 
PIP_SUBFIELD.DATA is 64 characters. 


PIP_FIELD: 
LL: Length of this logical record (See Note 1.). 
ID: GDS ID for PIP Data GDS Variable (X'12F5'). 
DATA: Character string containing PIP data. 


RETURN_CODE 


The primary and secondary return codes that may be returned on transaction program verbs 
are described in SNA Transaction Programmer's Reference Manual for LU Type 6.2 


RETURN_CODE 
PRIMARY_CODE: possible values: 
see SNA Transaction Programmer's Reference Manual for LU Type 6.2 
SECONDARY_CODE: possible values: 
see SNA Transaction Programmer's Reference Manual for LU Type 6.2 
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PIP_LIST 


PIP_LIST 


PIP_LIST: List of PIP data subfields. 


LU_ID 


LU_ID: ID of this LU. 


TCB_LIST_PTR 


TCB_LIST_PTR: Pointer to the list of TCBs for TP/PS processes at this LU. 


RCB_LIST_PTR | 


RCB_LIST_PTR: Pointer to the RCB_LIST for this TP/PS process. 


LUCB_LIST_PTR 


LUCB_LIST_PTR: Pointer to the list of LUCBs for Us know to this LU. 
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SENSE_DATA 


SENSE_DATA 


SENSE_DATA: 4-byte sense data 
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CHAPTER 5.1, PRESENTATION SERVICES--CONVERSATION VERBS 


GENERAL DESCRIPTION 


A PS process handles requests for LU serv- 
ices. A transaction program (TP) execution 
instance makes these requests by issuing 
verbs. The verbs are divided into catego- 
ries, and PS is divided into components. 
Each verb-processing component of PS proc- 
esses the verbs of one specific category. 
Presentation services for basic conversations 
(PS.CONV) is the component of PS that proc- 
esses verbs of the basic conversation catego- 
ry. Figure 5.1-1 on page 5.1-2 provides an 
overview of PS, showing the relationship of 
PS.CONV to the other PS components. 


The basic conversation verbs correspond to 
the most basic services provided by the LU. 
Other PS components, such as PS.MC ("Chapter 
5.2. Presentation Services--Mapped Conversa- 
tion Verbs") and PS.COPR ("Chapter 5.4. Pres- 
entation Services--Control-Operator Verbs") 
use basic conversation verbs in providing 
their higher-level functions. Open-API 


implementations may choose to expose only the © 


mapped conversation protocol boundary to 
user-application transaction programming, 
while leaving the lower-level basic conversa- 
tion protocol boundary "closed". 


See Chapter 5.0 for an overview of PS and its 
components, and of the relationship of PS to 
the other components of the LU. Refer to SNA 
Transaction Programmer's Reference Manual for 


LU Type 6.2 for a complete description of the 
basic conversation verbs. 


PS.CONV FUNCTIONS 


The functions of PS.CONV include: 


® Requesting the allocation and deallo- 
cation of conversation resources. 


® Maintaining and checking the basic con- 
versation state. 


® Transferring conversation data between 
the half-session and transaction program 
variables. 


@ Tracking logical record lengths. 
COMPONENT INTERACTIONS 


PS.CONV interacts with PS.VERB_ROUTER ("Chap- 
ter 5.0. Overview of Presentation Services''), 


Chapter 5.1.) 


the resources manager ("Chapter 3. LU 
Resources Manager''); and one or more 
half-session components ("Chapter 6.0. 
Half-Session"’). 


All verb service requests are routed through 
PS.VERB_ROUTER, which forwards basic conver- 
sation verbs to PS.CONV. After PS.CONV has 
performed the requested service, control is 
returned to the caller, with updated values 
in those variables that are the verb's 
returned parameters, or in which it requested 
a result to be returned. 


PS.CONV interacts with the resources manager 
(RM) to request allocation and deallocation 
of LU resources, such as conversations and 
associated control blocks, and to report pro- 
tocol errors. Since PS.CONV and RM may be in 
different processes, this interaction may 
occur by means of asynchronous inter-process 
communication (send/receive logic). RM also 
informs PS.CONV if a conversation being used 
by PS.CONV fails for some reason. 


PS.CONV interacts with one half-session proc- 
ess for each active conversation used by 
PS.CONV. Each half-session serves a single 
conversation. Since the TP may have active 
conversations with several partners simul- 
taneously, PS.CONV may be interacting with a 
number of different half-session processes. 


PS.CONV DATA-BASE STRUCTURE 


PS.CONV uses a number of control blocks and 
data structures. The most important ones are 
described here. See "Appendix A. Node Data 
Structures" for full details. 


Ree ORRETEOR EERE EERSTE = CEETTERECUSTTEED CRUD EERSTE = GEARED 


The LU control block (LUCB--see Figure 5.1-2 
on page 5.1-3) is used by PS.CONV. One LUCB 
exists for each LU in the node. The LUCB is 
identified by the LU ID, which is a unique 
identifier for each LU in the node. Each 
LUCB contains information such as the fully 
qualified LU name. 


Associated with each LUCB is aie TRANS- 
ACTION_PROGRAM_LIST. The TRANS- 
ACTION_PROGRAM_LIST for an LU contains an 
entry for each transaction program Known by 
the LU. The information in = a TRANS- 
ACTION_PROGRAM LIST entry ‘inciudes the trans- 
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Note: A dashed line denotes a synchronous (call/return) protocol boundary between components, 


while a solid line denotes an asynchronous (send/receive) protocol boundary. 


Overview of Presentation Services, Emphasizing Presentation Services for Basic 


Conversations 


Figure 5.1-1. 


action program name and whether it supports 
various optional features (e.g., sync point, 
mapped conversations ). 


Another list associated with each LUCB is the 
PARTNER_LU_LIST (see Figure 5.1-2 on page 
5.1-3). The PARTNER_LU_LIST contains one 
entry for each partner LU of the LU repres- 
ented by the LUCB. The PARTNER_LU entry con- 
tains information that is fixed for the 


specific partner LU, such as the local and 
fully qualified names of the partner LU. 


Associated with each PARTNER_LU entry is a 
MODE_LIST (see Figure 5.1-2 on page 5.1-3); 
which has one entry for each mode name that 
is defined for the particular partner LU 
name. The MODE entry contains information 
that is fixed on a mode basis, such as the 
mode name. 
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LUCB1 


Figure 5.1-2. LU Control Block List and Associated Lists 


LUCB_LIST 
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Transaction Control Block (TCB) 


The transaction control block (TCB--see Fig- 
ure 5.1-3 on page 5.1-4) contains information 
associated with the TP-PS process. One TCB 
exists for each TP-PS process. Each TCB con- 
tains a TCB ID, which is a unique identifier 
of the TP-PS process being represented by the 
TCB. The TCB ID is used in all communication 
between the resources manager and the PS 
servicing the transaction program. For exam- 
ple, when PS sends a record to the resources 
manager, it provides its TCB ID so that the 
resources manager will know, of all the 
transaction programs it manages, which PS 
process to send a reply to. 


Associated with each TCB is the 
RESOURCES_LIST, a list of the resources used 
by the TP-PS process. The RESOURCES_LIST has 
one entry for each resource (e.g., for each 
conversation) associated with the transaction 
program. 
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PS PROCESS DATA 


PS _PROCESS_DATA (page 5.0-19) contains data 
that is available to all procedures in the PS 
process. It contains information about this 
particular TP-PS process, such as the LU JD 
and the pointer to the RCB_LIST. It is ini- 
tialized by the root procedure 
(PS.INITIALIZE) of the PS process (page 
5.0-5) from parameters received from RM when 
the PS process is created. 


Resource Control Block (RCB) 


One resource control block (RCB--see Fig- 
ure 5.1-4 on page 5.1-5) represents each 
active conversation allocated to a trans- 
action program. The RCBs for all active con- 
versations in an LU are kept in the RCB_LIST. 
RCBs are added to or removed from the 
RCB_LIST by the LU resources manager, at the 
request of PS.CONV. RCBs are also linked to 
the RESOURCES LIST for the particular TP-PS 


5.1-3 


Figure 5. 1-3. 


RESOURCES_LIST 


TCB_LIST —_> 


Transaction Control Block (TCB) 
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process to which they are allocated. 
for the process contains» in its 
RESOURCES LIST, the list of RCBs_ for 
resources (such as conversations) allocated 
to the process. 


The TCB 


An RCB for a conversation contains informa- 
tion pertaining to a particular conversation, 
such as its resource ID, state, and charac~- 
teristics (established when the conversation 
is allocated). Components of PS will update 
rage fields of the RCB as the conversation 
is used. 


The RCB is identified by a unique RCB ID. 
This ID accompanies most transaction program 
verb issuances (as the RESOURCE parameter) to 
identify the conversation to which the verb 
is to be applied. The RCB also contains the 
TCB ID of its owning TP-PS process, and the 
HS ID of the local half-session that carries 
the conversation'’s data. Other fields asso- 
ciated with the RCB are discussed in wsore 
detail below. 


FSM_CONVERSATION (page §.1-63) is a 
finite-state machine that tracks the 
state of the conversation associated with 
the RCB. The state of FSM_CONVERSATION 
is the state of the conversation. from the 

ef the local IP. For example, 
the conversation changes from receive to 
send state when the transaction program 


is notified by a WHAT RECEIVED = SEND 
from a receive verb. The state of the 
conversation does not change until 


PS.CONV has actually notified the trans- 
action program, even though the send 
indication may have arrived from the 
half-session sometime earlier. 


PS_TO_HS_RECORD (page A-24) is used as a 
buffer to contain data that has been gen- 
erated by verb processing but that has 
not yet been sent to the half-session. 
The record is sent to the half-session 
when either a maximum size is exceeded or 
as the result of some transaction program 
verb (e.g. FLUSH, CONFIRM). 


FSM_ERROR_OR_FAILURE (page 5.1-65) is a 
finite-state machine that stores error or 
failure records (which may arrive from RM 
or the half-session) until they can be 
returned to the TP in verb parameters. 


HS_TO_PS_BUFFER_LIST contains ao ilist of 
records that have been received from the 
half-session but not yet passed to the 
transaction program. 


SECURITY_SELECT initially contains the type 
of end-user verification: NONE, SAME, or 
PGM. This value might be downgraded from 
P6M to NONE or SAME to NONE (see "Chapter 
3. LU Resources Manager" for details of 
when RM downgrades end-user verifica- 
tion). The Attach is built using the 
SECURITY_SELECT value. 3 


VERB PARAMETERS 


The TP requests LU services by issuing verbs. 
A verb and its parameters are passed as 
parameters to PS_CONV (page 5§.1-10). The 
service requested is identified by the verb 
name and the supplied parameter fields, and 
some results of the service (along with any 
other pertinent incoming data) are returned 
to the TP in the returned parameter fields. 
Each verb issuance has: 


® An indicator of which verb 
issued (e.g., ALLOCATE, CONFIRM) 

® Some supplied parameters, including (typ- 
ically) an identifier of the conversation 
on which the verb is being issued 

® Some returned parameters, including (typ- 
ically) a return code telling whether the 
requested service was peetonees success~ 
fully | 


is baing 


Some examples of exceptions to these parame- 
ter rules are the following. ALLOCATE does 
not supply a conversation ID (although it 
does return one), while WAIT supplies a whole 
list of conversation IDs. CONFIRMED and 
FLUSH do not need any returned parameters. 


The basic conversation verbs and their param- 


eters are fully described in SNA Transaction 
oo Reference Manuel for LY Ive 


PS-RM RECORDS 


PS.CONV sends PS_TO_RM_RECORDs (page A-25) to 
RM and receives RM_TO_PS RECORDs (page A-32) 
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HS_TO_PS_BUFFER_LIST 


RCB_LIST 


FSM_ERROR_OR_FAILURE 
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Resource Control Block (RCB) 


from RM. There are several types of PS_TO_RM 
records. Each contains a TCB ID identifying 
the PS process that sent the record, and pos- 


sibly additional fields. RM_TO_PS_RECORDs 
are usually sent in reply to a 
PS_TO_RM_RECORD request, as shown in Fig- 
ure 5.1-5. 
PS.CONV Request RM Response 
ALLOCATE_RCB RCB_ALLOCATED 
GET_SESSION SESSION_ALLOCATED 


DEALLOCATE_RCB RCB_DEALLOCATED 


Figure 5.1-5. PS.CONV Requests and 


Associated RM Responses 


The only exception is CONVERSATION FAILURE, 
which is sent, unsolicited, to PS.CONV when a 
conversation being used by PS.CONV fails. 


PS-HS RECORDS 


PS.CONV sends PS_TO_HS_RECORDs (page A-24) 
to a half-session and receives 
HS_TO_PS_RECORDs (page A-12) from a 
half-session. 


A PS_TO_HS_RECORD contains a VARIANT_NAME 
field, identifying the particular variant; 
and additional fields, in the case of 
SENO_DATA_RECORD. SEND_DATA_RECORD is used 
to send data and RH information to the 
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half-session when the local transaction pro- 
gram is in send state for the conversation. 
Included in the SEND DATA_LRECORD is the 
transaction program data to be sent and an 
encoding of the RH bits (see "Appendix D. RH 
Formats") that are to be set by the 
half-session when the data is sent to the 
remote LU. Data to be sent to a half-session 
with a  SEND_DATA_RECORD is buffered by 
PS.CONV until either a maximum data length 
(given by RCB.MAX_BUFFER_LENGTH) is exceeded, 
or the transaction program issues a verb that 
forces the data to be passed on for trans- 
mission f(e.g., CONFIRM, RECEIVE AND_WAIT, or 
DEALLOCATE }. 


The other PS_TO_HS_RECORD variants are sent 
to the half-session only when the local 
transaction program is in receive state. 
These include CONFIRMED, used to reply posi- 
tively to ao previous CONFIRM record; 
REQUEST_TO_SEND, used to request the send 
indicator from the partner transaction pro- 
gram; and SEND_ERROR, used to send -RSP( 0846) 
to the partner LU. 


The HS_TO_PS_RECORD contains a VARIANT_NAME 
field and an HS ID field. The HS ID is used 
to identify which half-session sent the 
record to PS.CONV. The HS_TO_PS_RECORD is 
symmetric to the PS_TO_HS_RECORD. That is, 
RECEIVE_DATA corresponds to a § SEND_DATA 
issued by the renote PS.CONV, CONFIRMED cor- 
responds to CONFIRMED, RECEIVE_ERROR to 
SEND_ERROR, and REQUEST_TO_SEND to 
REQUEST_TO_SEND. RSP_TO_REQUEST_TO_SEND has 
no equivalent in the PS_TO_HS_RECORD, since 
RSP_TO_REQUEST_TO_SEND is generated by the 
remote half-session. 
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* TRACKING LOGICAL RECORD LENGTH 


Transaction programs using a basic conversa- 
tion must ensure that the data they exchange 
is formatted into logical records. The 
length of a logical record is given by the 
low-order 15 bits of the first two bytes of 


the record. The high-order bit is the "con- 
tinuation bit", which is used for GDS vari- 
ables by PS .MC (see "Chapter 5.2. 


Presentation Services--Mapped Conversation | 
The value in = the Length field. 


Verbs"). 
includes the length of the field itself; thus 
the length value is normally in the range 
2-32767. Length values of 0 and 1 are used 
to indicate a PS header. (See "Chapter 5.3. 
Presentation Services--Sync Point Services 
Verbs" for more details.) 


When sending data, the transaction program is 
responsible for correctly setting the Length 
bytes of each logical record. The amount of 
data sent by a SEND_DATA verb need have no 
relation to a logical record. 


PS.CONV performs some checking of the logical 
record Length field supplied by the trans- 
action program. The value of the Length 
field must be greater than 1, wnless 
TCB .CONTROLLING_COMPONENT > SERV- 
ICE_COMPONENT, that is, unless some PS serv- 
ice component (e.g., PS.MC or PS.SPS) is 
sending a PS header in the record on behalf 
of a transaction program. 


Certain verbs (e.g.» CONFIRM) may be validly 
issued only at logical record boundaries. 
PS.CONV enforces this rule by remembering how 
many bytes are remaining to be sent in the 
current logical record, and terminating the 
transaction program abnormally if this 
remainder is not 0 when the verb is issued. 
SEND_ERROR and DEALLOCATE TYPE(ABEND) are the 
only verbs that can prematurely truncate a 
logical record. 


PS.CONV also tracks the value of the Length 
field on logical records received from the 
partner transaction program. Logical records 
with a Length of 1 are passed to PS_SPS. 
PS.CONV maintains a count of the number of 
bytes remaining in the current logical 
record. PS.CONV performs an optional receive 
check to determine if the partner LU has vio-~ 
lated PS protocols by allowing the partner 
transaction program to invalidly truncate the 
logical record. Only an FMH-7 can validly 
truncate a logical record. 


Finally, when a receive verb is issued with 
FILL(LL), PS uses the receive count remainder 
to determine how many bytes of received data 
to pass to the transaction program. 


MAINTAINING AND CHECKING THE BASIC CONVERSA- 
TION STATE 


PS.CONV maintains the current state of each 
conversation in FSM_CONVERSATION (page 
5.1-63). As noted earlier, the state of 
FSM_CONVERSATION is the state of the conver- 


sation as viewed by the local transaction 
program. 


The state of the conversation may change as a 
result of verbs issued by the transaction 
program; e.g.» PREPARE _TO_RECEIVE changes the 
state from send to receive. These inputs 
have DIRECTION=S in FSM_CONVERSATION. The 
state may also change as a result of data or 
indicators received from tha half-session; 
e.g.» receiving the send indicator changes 
the state of the conversation from receive to 
send. These inputs have: DIRECTION=R in 
FSM_CONVERSATION. 


The current state of the conversation deter- 
mines the verbs that can be validly issued; 
e.g.» a SEND _DATA verb cannot be issued in 
receive state. 


VERB PROCESSING 


Details of PS.CONV's processing of some verbs 
are described here. See also "Chapter 2. 
Overview of the LU" for more flow diagrams 
corresponding to the processing of these and 
other verbs. 


Verb Checking 


PS.CONV performs a nusber of checks on verb 
requests received from the transaction pro- 
gram. These include: 


e Parameter checks, such as checking that: 


- The parameters specified on the ALLO- 
CATE are supported by the LU. 

~- The verb conforms to the SYNC_LEVEL 
of the conversation (as specified on 
ALLOCATE). 

~ The DATA parameter on SEND_DATA con- 
tains a valid Length field (see 
"Tracking Logical. Record Length"). 


¢ $tate checks, such as checking that: 


-~ The verb can be issued in the current 
conversation state (see “Maintaining 
and Checking the Basic Conversation 
State”). 

~-~ The transaction program has completed 
the current logical record, if neces- 
Sary (see "Tracking Logical Record 
Length"). 


ALLOCATE 


Processing of the ALLOCATE verb by PS.CONV 
includes: 


* Requesting that RM allocate a resource 
control block (RCB). 


@ Requesting that RM sitoceie a session for 


the conversation.. 


° cresting an Attach FMH-5. 
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The order of performing the last two items 
depends on the supplied RETURN_CONTROL param- 
eter of the ALLOCATE verb, as described 
below. 


A conversation resource is represented by a 
resource control block (RCB--see ''PS.CONV 
Data-Base Structure" on page 5.1-1). PS.CONV 
requests the creation of an RCB by sending an 
ALLOCATE_RCB record to the resources manager 
(RM) and waiting for an RCB_ALLOCATED record 
in reply. If RETURN_CONTROL( IMMEDIATE) is 
specified, the ALLOCATE_RCB record is a con- 
posite request for the creation of an RCB and 
the allocation of a first-speaker session. 
This situation is indicated to RM by setting 
ALLOCATE_RCB.INMEDIATE_SESSION = YES. 


After the RCB has been created, PS.CONV 
requests the resources manager to allocate a 
session for use by the conversation (if a 
session has not already been allocated as a 
result of IMMEDIATE_SESSION = YES). PS.CONV 
does this by sending a GET_SESSION record to 
RM and waiting for a SESSION ALLOCATED record 
in reply. 


If DELAYED_ALLOCATION_PERMITTED is specified 
on the ALLOCATE, the session allocation 
request is delayed until either the PS.CONV 
send buffer is exceeded or the transaction 
program issues a verb that causes the data to 
be passed on for transmission. Furthermore, 
PS.CONV instructs RM (via the GET_SESSION 
record) whether to bid for (request use of) 
the session with or without sending the buf- 
fered data. The bid is to be sent without 
data if the data buffered thus far would not 
require a definite response from the partner 
LU. Otherwise, the bid is to be sent with 
data. 


The type of end-user verification is 
requested in the ALLOCATE as NONE, SAME, or 
PGM. See SNA Transaction Programmer's Refer- 
ence Manual for LU Type 6.2 for a more com- 
plete description of the security parameter 
relating to end-user verification. 


PS.CONV creates an Attach FMH-5 based on the 
parameter settings in the ALLOCATE verb and 
in the RCB. The Attach is inserted in 
RCB.PS_TO_HS_RECORD.DATA, to be sent later. 
When processing an ALLOCATE verb, the Attach 
could be created prior to assignment of the 
session, thus causing the previously built 
Attach to differ from the SECURITY_SELECT 
field of the RCB as a result of a security 
downgrade. In these cases, it is necessary 
for PS to rebuild the Attach to match the 
updated value in the SECURITY_SELECT field. 


POST ON RECEIPT 

The POST_ON_RECEIPT verb establishes the 
posting conditions for the conversation. The 
post conditions (FILL = BUFFER or LL, and 


LENGTH) are retained in the RCB associated 
with the conversation. The posting status 
(reset, pending post, or posted) of a conver- 
sation is maintained by FSM_POST, also in the 
RCB. Whenever PS.CONV receives information 
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from the half-session, the posting conditions 
are checked, and the state of FSM_POST is 
updated if necessary. If POST_ON_RECEIPT has 
been issued, the state of FSM _POST may be 
checked by calling TEST_PROC on page 5&.1-27 . 
This procedure is used by the WAIT verb to 
determine whether the post conditions have 
been satisfied for any of several conversa- 
tions. 


REQUEST TQ SEND 
When the transaction program issues a 


REQUEST_TO_SEND verb, PS.CONV checks the con- 
versation state to see if the verb can be 
validly issued now, and checks that the con- 
versation is still active. If so, PS.CONV 
sends a REQUEST_TO_SEND record to the appro- 
priate half-session process and then waits 
for a RSP_TO_REQUEST_TO_SENOD record from the 
half-session. By waiting for a response from 
the half-session before returning to the 
transaction program, PS.CONV prevents the 
transaction program from flooding the network 
with expedited-flow FMD RUs. 


On receipt of a REQUEST_TO_SEND record from a 
half-session, PS .CONV sets 
RCB.RQ_TO_SEND_RCVD to YES, and notifies the 
transaction program at the earliest oppor tu- 
nity. 


SEND ERROR 


Processing of the SEND_ERROR verb by PS.CONV 
includes: 


e If the TP issuing the verb is in receive 
state: 


- Sending a SEND_ERROR record to the 
hal f-session. This causes a 
-~RSP(0846) to be sent to the partner 
LU. 

- Waiting until EC is received from the 
partner LU. The half-session purges 
all data until EC is received. 


Note: If the TP issuing the verb is in send 
state, the above two steps are not performed. 


® Creating an FMH-7 with the sense data 
based on the SEND_ERROR type and the cur- 
rent state of the conversation. 


® Creating a log data variable, if log data 
is present. 


In the case of both sides of a conversation 
issuing SEND_LERROR, the side that was in 
receive state always wins the SEND_ERROR 
race. Figure 5.1-6 on page 5.1-8 shows a 
flow diagram for a simple SEND_ERROR race. 


Figure 5.1-7 on page 5.1-8 shows a SEND_ERROR 
race with deallocation. In this case, nei- 
ther error gets reported to the other side. 
This problem could be avoided by following 
the SEND_ERROR with a PREPARE_TO_RECEIVE, as 
shown in the previous figure. 


5.1-7 


On receipt of a RECEIVE_ERROR record from the 
half-session (as a result of the partner LU 
sending ai -RSPI0846]}, PS.CONV sends 
end-of-chain to the half-session, if it has 


not already done so. It then receives the 
exmauted FMH-7 and notifies the transaction 
program, at the earliest opportunity, with a 
return code based on the FMH-7 sense data. 


HS PS. CONV Ip 


Ip PS .CONV HS 
SEND_DATA SEND_ERROR 
, > Co hecrieamtees 
< =— — RC=OK — - — 
SEND_ERROR ~RSP( 0846 ) SEND_ERROR 
< - — RCSOK - ~ — | 
PREPARE_TO_RECEIVE 
> purge 
<=— ~~ RCZOK — ~ — 
SEND_DATA_RECORD 
> Vv 
FMH7,RQE1,EC,CD RECEIVE_DATA 
maemnaeeemensacmnnegndensnceminnsts > saenesammnncnonneeeenmemansennseeenenanee SP 
i - —- RC=O0K —> 
RECEIVE ERROR 
C cemernceemsntoneeneaasanenanenpanianminsene 
RECEIVE ANO_WAIT 
noresameneenanueammacnmaengemummaenmneeamennagsanes SP 
RC=PROG_ERROR_ PURGING 
cess i: <as'5 Si S- “alla< 
Figure 5.1-6. SEND_ERROR Race 
IP PS. CONV HS HS P3.CONY IP 
SEND_DATA SEND_ERROR 
> , 
<< = ww RC-OK a a) 
SEND_ERROR ~RSP( 0846 ) SEND_ERROR 
> < , 
<—— RC=OK - - - | 
DEALLOCATE TYPE( FLUSH) 
one > purge 
< = — RC=OK - - - | 
SEND_DATA_RECORD 
> V 
FMH7,RQE1,EC,CEB RECEIVE _DATA 


ns 


RECEIVE_ERROR 
© cereronmntinermenmnnmanananctaniannntaancenaneneentat 


(RECEIVE_ERROR 
ignored by PS_.CONV) 


Figure 5.1-7. SEND_ERROR Race with Deallocation 


RC=DEALLOCATE_NORMAL 
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PROTOCOL ERRORS 


PS.CONV contains a number of optional receive 
checks to determine if the partner LU has 
violated SNA-defined protocols. Examples of 
protocol violations checked by PS.CONV 
include: 


e §6Sending data when in receive state 

® Invalidly truncating a logical record 
(see “Tracking Logical Record Length" on 
page 5.1-6 ) 

® Sending an incorrectly formatted FMH-7 


When PS.CONV detects a protocol error, it 
requests that RM deactivate the session and 
sets FSM_ERROR_OR_FAILURE to indicate that a 
conversation failure (protocol error } 
occurred. 


CONVERSATION FAILURES 


PS.CONV is notified of a conversation failure 
by the CONVERSATION_FAILURE record, sent by 
RM. The conversation failure may result from 
either session outage or a protocol vio- 
lation. 


On receipt of a CONVERSATION_FAILURE record, 
PS.CONV sets RCB.FSM_ERROR_OR_FAILURE to 
indicate ei ther CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR. PS.CONV noti- 
fies the transaction program of the conversa- 
tion failure by returning a RESOURCE_FAILURE 


| return code on the next verb that allows one. 
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HIGH-LEVEL PROCEDURES 


PS_CONV 


FUNCTION: Receives conversation verbs issued by the TP or by other PS components, and 
calls appropriate procedures to process them. 


INPUT: _ Transaction program verb and parameters 


OUTPUT : Refer to the procedures that are called from this process for the specific 
outputs. | 


Referenced procedures, FSMs,» and data structures: 


ALLOCATE_PROC page 5.1-11 
CONFIRM_PROC page 5.1-12 
~ CONFIRMED_ PROC page 5.1-14 
DEALLOCATE_PROC page 5.1-15 
FLUSH_PROC page 5.1-17 
GET_ATTRIBUTES_ PROC page 5.1-18 
POST_ON_RECEIPT_PROC | page 5.1-18 
PREPARE_TO_RECEIVE_PROC page 5.1-19 
RECEIVE _AND_WAIT_PROC page 5.1-20 
RECEIVE_IMMEDIATE_PROC page 5.1-22 
REQUEST_TO_SEND_PROC page 5.1-23 
SEND_DATA_PROC page 5.1-24 
SEND_ERROR_PROC page 5.1-26 
TEST_PROC © page 5.1-27 


Select based on the transaction program verb: 

When ALLOCATE 

Call ALLOCATE_PROC(verb parameters) (page 5.1-11). 
When CONFIRM 

Call CONFIRM_PROC(verb parameters) (page 5.1-12).. 
When CONFIRMED | 

Call CONFIRMED_PROC(verb parameters) (page 5.1-14). 
When DEALLOCATE 

Call DEALLOCATE_PROC( verb parameters) (page 5.1-15). 
When FLUSH 

Call FLUSH_PROC(verb parameters) (page 5.1-17). 
When GET_ATTRIBUTES 

Call GET_ATTRIBUTES_PROC( verb parameters) (page 5.1-18). 
When POST_ON_RECEIPT 

Call POST_ON_RECEIPT_PROC(verb parameters) (page 5.1-18). 
When PREPARE_TO_RECEIVE 

Call PREPARE_TO_RECEIVE_PROC(verb parameters) (page 5.1-19). 
When RECEIVE_AND_WAIT 

Call RECEIVE_AND_WAIT_PROC(verb parameters) (page 5.1-20). 
When RECEIVE _IMMEDIATE 

Call RECEIVE_IMMEDIATE_PROC( verb parameters) (page 5.1-22). 
When REQUEST_TO_SEND 

Call REQUEST_TO_SEND_PROC( verb parameters) (page 5.1-23). 
When SEND_DATA 

Call SEND_DATA_PROC(verb parameters) (page 5.1-24). 
When SEND_ERROR 

Call SEND_ERROR_PROC(verb parameters) (page 5.1-26). 
When TEST 

Call TEST_PROC( verb parameters) (page 5.1-27). 
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ALLOCATE_PROC 
ALLOCATE_PROC 


Handles allocation of new resources to the transaction program. 


If the ALLOCATE parameters are valid, this procedure requests that RM create a 
new resource control block (RCB). If the supplied RETURN_CONTROL parameter 
specifies IMMEDIATE, PS at this time also raquests RM to acquire a session for 
use by the conversation resource. If the RETURN_CONTROL is set to 
DELAYED_ALLOCATION PERMITTED or WHEN_SESSION_ALLOCATED, PS sends a separate 
session request to RM at a later time. 


ALLOCATE verb with parameters; RCB_ALLOCATED record received from RM 
ALLOCATE_RCB to RM 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
RM page 3-18 
RCB_ALLOCATED_PROC page 5.1-48 
WAIT_FOR_RM_REPLY page 5.1-69 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
ALLOCATE_RCB page A-25 
RCB_ALLOCATED page A-32 
MODE page A-3 


Check ALLOCATE for ABEND conditions (see ALLOCATE verb in 
SNA Iransaction Programmer's Reference Manual for LU Type 6.2). 


If ABEND conditions found then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 


Else | 
If a MODE control block exists for the LU_LNAME and MODE_NAME parametars specified in the 
ALLOCATE then | 
Create and initialize ALLOCATE_RCB request record with the 
parameters of the ALLOCATE. 
Send ALLOCATE_RCB request to RM. 
Call WAIT_FOR_RM_REPLY to receive RCB_ALLOCATED from RM (page 5.1-60). 
Call RCB_ALLOCATED_PROC(RCB_ALLOCATED, ALLOCATE parameters), 
to build an FMH-5 Attach header, and to set the RETURN_CODE 
parameter to the appropriate value (page 5.1-48). 


Else 
Set RETURN_CODE of the ALLOCATE verb to PARAMETER_ERROR. 
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CONFIRM_PROC 


5.1-12 


CONFIRM_PROC 


FUNCTION: 


Handles the CONFIRM verb processing. 


If it is appropriate for the transaction program to issue a CONFIRM for the 
specified conversation (i.e., the SYNC_LEVEL of the conversation for which the 
CONFIRM was issued is CONFIRM or SYNCPT and any data issued by the transaction 
program is on a logical record boundary), this procedure first retrieves any 
records from HS and RM. Appropriate action is taken depending upon which, if 
any,» record was received (as reflected by the state of FSM_ERROR_OR_FAILURE). 


CONFIRM verb parameters 
See below. 


If a CONVERSATION_FAILURE has been received from the resources manager, PS 
returns to the transaction program after setting the RETURN_CODE parameter of 
the CONFIRM to RESOURCE_FAILURE. 


If the local LU has detected an error while attempting to allocate a session 
to this conversation, but PS has not yet had the opportunity to relay that 
information to the transaction program it does so at this time by setting the 
RETURN_CODE parameter of the CONFIRM to reflect the type of allocation error. 


If a RECEIVE_ERROR has been received from HS, PS sends a SEND DATA record with 
the TYPE field set to PREPARE_TO_RCV_FLUSH to HS. (Any data in the RCB send 
buffer mwas purged when the RECEIVE_ERROR record was received.) PS then maits 
for the expected FMH-7 error message to arrive. The RETURN_CODE. parameter of 
the CONFIRM is set based on the sense data carried in the FMH-7. 


If there are no error or failure conditions, COMPLETE_CONFIRM_PROC 
5.1-29) is called to complete the processing of the CONFIRM. 


(page 


Referenced procedures, FSMs, and data structures: 


DEALLOCATION_CLEANUP_PROC page 5.0-13 
PROCESS_RM_OR_HS_TO_PS_RECORDS page 5.1-47 
SEND_DATA_TO_HS_ PROC page 5.1-52 
POST_AND_WAIT_PROC page 5.1-40 
DEQUEUE_FMH7_PROC page 5.1-36 
COMPLETE_CONFIRM_PROC page 5.1-29 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 
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Find the RCB for the conversation identified in the RESOURCE parameter. 


If RCB.SYNC_LEVEL = NONE and the send data is not at a logical record boundary then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
Else 
If executing FSM_CONVERSATION(S, CONFIRM, RCB) 
(page 5.1-63) would cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 


Select based on the state of FSM_ERROR_OR_FAILURE: 
When CONV_FAILURE_PROTOCOL_ERROR 
Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
When CONV_FAILURE SON 
Set RETURN_CODE to RESOURCE _FAILURE_ RETRY. 
Call FSM_CONVERSATION(R, RESOURCE _FAILURE_RC, RCB) (page 5.1-63). 
When ALLOCATE _FAILURE_RETRY, ALLOCATE_FAILURE_NO_RETRY, 
or SYNCLEVEL_NOT_SUPPORTED 
Set RETURN_CODE to ALLOCATION_ERROR with a subcode of 
ALLOCATION _FAILURE_RETRY, ALLOCATION _FAILURE_NO_RETRY, or 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 
When RCVD_ERROR 
Set RCB.PS_TO_HS_RECORD to PREPARE_TO_RCV_FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
Call POST_AND_WAIT_PROC(RCB, LL, X'7FFF') to post the 
resource when the whole FMH-7 is received (page 5.1-40). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON then 
Set RETURN_CODE to RESOURCE _FAILURE_RETRY. 
Else 
Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE _FAILURE_RC, RCB) (page 5.1-63). 
Else 
Call DEQUEUVE_FMH7_PROC(CONFIRM verb parameters, RCB) (page 5.1-36). 
When NO_RQS 
Call COMPLETE_CONFIRM_PROC(CONFIRM verb parameters, RCB) (page 5.1-29). 


If REQUEST_TO_SEND has been received but not reported to TP then 
Set returned REQUEST_TO_SEND_RECEIVED parameter to YES. 
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CONF IRMED_PROC 


5.1-14 


CONFIRMED_ PROC 


Handles CONFIRMED verb processing. 


PS first retrieves any records from HS. and RM. 


is taken 
depending upon which, if any, record was received. 


Appropriate action 


CONFIRMED verb parameters. 
See below. 


If a CONVERSATION_FAILURE record has been received from the resources manager, 
PS returns to the transaction program without sending any data to HS. Since 
CONFIRMED verb does not have a RETURN_CODE parameter, the conversation failure 
cannot be reported to the transaction program at this time. PS remembers the 
failure (via FSM_ERROR_OR_FAILURE) and reports it to the transaction program 
ata later time (i.e., when the transaction program issues a verb with a 
RETURN_CODE parameter ). 


If a CONVERSATION_FAILURE record has not been received PS sends a CONFIRMED 
record (page A-24) to HS. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
HS page 6.0-3 
‘PROCESS_RM_OR_HS_TO_PS_RECORDS page 5.1-47 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 
CONFIRMED page A-24 
Find the RCB for the conversation identified by the RESOURCE parameter. 


If executing 


FSM_CONVERSATION(S, CONFIRMED, RCB) (page 5.1-63) 


would cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 


Else 


Call PROCESS_RM_OR_HS_TO_PS_RECORD(RCB.RCB_ID, NO_SUSPEND) 
(page 5.1-47). | — | 
If state of FSM_ERROR_OR_FAILURE is NO_RQS (see Note 2) then 
Call FSM_CONVERSATION(S, CONFIRMED, RCB) (page 5.1-63). 


Create 


a CONFIRMED record, initialize it, and send it. to HS. 


Else (errors reported) 
Do nothing (see Note 1). 
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DEALLOCATE_PROC 
DEALLOCATE_PROC 


FUNCTION: Handles the deallocation of resources. 


If the resource specified in the DEALLOCATE is a valid resource and the con- 
versation is in a pertinent state, PS calls the appropriate deallocation pro- 


cedure to continue processing the DEALLOCATE. 
DEALLOCATE verb parameters 


The pertinent deallocation procedure is called. When appropriate, PS sends 
DEALLOCATE_RCB to RM. 


Referenced procedures, FSMs, and data structures: 


DEALLOCATION_CLEANUP_ PROC page 5.0-13 
DEALLOCATE_FLUSH_PROC page 5.1-35 
DEALLOCATE_CONFIRM_PROC page 5.1-33 
DEALLOCATE_ABEND_PROC page 5.1-32 
FSM_CONVERSATION page 5.1-63 
DEALLOCATE_RCB page A-26 

RCB page A-7 


Find the RCB for the conversation identified in the supplied RESOURCE 
parameter of the DEALLOCATE. 
Select based on the following criteria: 
When TYPE parameter of DEALLOCATE is FLUSH, or TYPE parameter is SYNC_LEVEL 
and RCB.SYNC_LEVEL is NONE 
If executing FSM_CONVERSATION(S, DEALLOCATE_FLUSH, RCB) (page 5.1-63) would 
cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
Call DEALLOCATE_FLUSH_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-35). 
Purge all records from HS to PS process. 
Create DEALLOCATE_RCB, initialize it, and send it to RM. 
When TYPE parameter is CONFIRM 
If executing FSM_CONVERSATION(S, DEALLOCATE_CONFIRM, RCB) (page 5.1-63) would 
cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
If RCB.SYNC_LEVEL is CONFIRM or SYNCPT then 
Call DEALLOCATE_CONFIRM_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-33). 
Else 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
When TYPE parameter is SYNC_LEVEL and RCB.SYNC_LEVEL = CONFIRM 
If executing FSM_CONVERSATION(S, DEALLOCATE_CONFIRM, RCB) (page 5.1-63) would 
cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
Call DEALLOCATE_CONFIRM_PROC(DEALLOCATE, RCB) (page 5.1-33). 
When TYPE parameter is SYNC_LEVEL and RCB.SYNC_LEVEL = SYNCPT 
If executing FSM_CONVERSATION(S, DEALLOCATE_DEFER, RCB) (page 5.1-63) would 
cause a state-check (>) condition then 
Execute the corresponding output cove tn the FSM. 
Else 
If the data sent by TP is on a logical record boundary then 
Cal?! FSM_CONVERSATION(S, DEALLOCATE_DEFER, RCB) (page 5.1-63). 
Set RETURN_CODE to OK. 
Else 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
When TYPE parameter is ABEND_PROG, ABEND_SVC, or ABEND_TIMER 
If executing FSM_CONVERSATION(S, DEALLOCATE_ABEND, RCB) (page 5.1-63) would 
cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
Call DEALLOCATE_ABEND_PROC(DEALLOCATE verb parameters, RCB) (page 5.1-32). 
Purge all records from HS to PS process. 
Create DEALLOCATE_RCB, initialize it, and send it to RM. 
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DEALLOCATE_PROC 


When TYPE parameter is LOCAL | 
If executing FSM_CONVERSATION(S, DEALLOCATE_LOCAL, RCB) (page 5.1-63) would 
cause a state-check (>) condition then | 
Execute the corresponding output code in the FSM. 

Else | 
Call FSM_CONVERSATION(S, DEALLOCATE_LOCAL, RCB) (page 5.1-63). 
Set RETURN_CODE to OK. } 

Purge all records from HS to PS process. 
Create DEALLOCATE_RCB record, initialize it, and send it to RM. 
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FLUSH_PROC 
FLUSH_PROC 


FUNCTION: Handles the FLUSH verb processing. 


The procedure first receives records from RM and HS. Appropriate action is 
taken depending upon the type of the received record as indicated by the 
FSM_CONVERSATION and FSM_ERROR_OR_FAILURE states. 


INPUT: FLUSH verb parameters, records from RM and HS 
OUTPUT: See below. 


NOTES: 1. If PS has received a RECEIVE_ERROR from HS, or no error records have been 
received, PS sends any data remaining in the RCB send buffer to HS with the 
TYPE field of the SEND_DATA set to FLUSH, PREPARE_TO_RCV_FLUSH, or DEALLO- 
CATE_FLUSH, depending on the state of the conversation. (If a RECEIVE ERROR 
was received, any data in PS‘s send buffer has already been purged. )} 


If FSM_ERROR_OR_FAILURE indicates that a conversation failure or allocation 
error has occurred, PS returns to the transaction program without sending any 
data to HS. Since FLUSH does not have a RETURN_CODE parameter, the error can- 
not be reported to the transaction program at this time. PS remembers the 
error (via FSM_ERROR_OR_FAILURE) and reports it to the transaction program at 
a later time (i.e., when PS receives a record from the transaction program 
that has a RETURN_CODE field). 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
HS page 6.0-3 
RM page 3-18 
PROCESS_RM_OR_HS_TO_PS_RECORDS page 5.1-47 
SEND_DATA_TO_HS_ PROC page 5.1-52 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 
DEALLOCATE_RCB page A-26 


Find RCB for the conversation identified by the RESOURCE parameter. 
If executing FSM_CONVERSATION(S, FLUSH, RCB) (page 5.1-63) would 
cause a state-check (>) condition then 

Execute the corresponding output code in the FSM. 


Else 
Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 


If the state of FSM_ERROR_OR_FAILURE (page 5.1-65) 
1s RCVD_ERROR or NO_RQS then 


Select based on state of FSM_CONVERSAT7ON (page 5.1-63): 
When SEND 
Set RCB.PS_TO_HS_RECORD.TYPE to FLUSH. 
When PREP_TO_RCV_DEFER 
Set RCB.PS_TO_HS_RECORD.TYPE to PREPARE_TO_RCV_FLUSH. 
When DEALL_DEFER 
Set RCB.PS_TO_HS_RECORD.TYPE to DEALLOCATE_FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
If state of FSM_CONVERSATION is DEALL_DEFER then 
Send a DEALLOCATE_FLUSH record to HS. 
Purge all records from HS to this PS. 
Create DEALLOCATE_RCB, initialize it, and send it to RM. 
Call FSM_CONVERSATION(S, FLUSH, RCB) (page 5.1-63). 
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GET_ATTRIBUTES_ PROC 


FUNCTION: Handles requests for information about a conversation. 


Information about the conversation resource is retrieved from the pertinent 
control blocks, and placed in the returned parameters of the GET_ATTRIBUTES 


verb. 

INPUT; GET_ATTRIBUTES verb parameters 

OUTPUT: GET_ATTRIBUTES verb returned parameters containing information about the con- 
versation 


Referenced procedures, FSMs, and data structures: 


FSM_CONVERSATION page 5.1-63 
LUCB page A-l 
TCB page A-10 
PARTNER_LU page A-2 
RCB page A-7 


Find the RCB for the conversation identified in the supplied RESOURCE parameter. 


Set the GET_ATTIBUTES returned parameters as follows: 
OWN _ FULLY _QUALIFIED_LU_NAME to LUCB.FULLY_QUALIFIED_ LU NAME» 
PARTNER _ LU_ NAME to RCB. LU_NAME, 
PARTNER_FULLY_QUALIFIED_LU_NAME to PARTNER_LU.FULLY_QUALIFIED_LU_NAME, 
MODE_NAME to RCB.MODE_NAME> 
SYNC_LEVEL to RCB.SYNC_LEVEL, 
SECURITY_PROFILE to TCB. INITIATING _SECURITY.PROFILE, 
SECURITY, USER_ID to TCB. INITIATING _SECURITY.USERID. 
Call FSM_CONVERSATION(S, GET_ATTRIBUTES, RCB) (page 5.1-63). 


POST_ON_RECEIPT_PROC 


Performs the processing of the POST_ON_RECEIPT verb. 


The procedure updates FSM_CONVERSATION and FSM_POST, saves the post conditions 
in the RCB, and retrieves any records originated in RM and HS. The data just 
received from RM or HS may cause the resource to be posted. 

POST_ON_RECEIPT verb parameters 


Updated FSM_CONVERSATION, FSM_POST, and post conditions in the RCB 


Referenced procedures, FSts, and data structures: 


PROCESS_RM_OR_HS_TO_PS_RECORDS page 5.1-47 
FSM_CONVERSATION page 5.1-63 
FSM_POST page 5.1-66 
RCB page A-7 


Find the RCB for the conversation identified by the RESOURCE parameter. 
If executing FSM_CONVERSATION(S, POST_ON_RECEIPT, RCB) (page 5. 1-63). 
would cause a state-check (>) condition then 

Execute the corresponding output code in the FSM. 


Else 
_ \ Call FSM_CONVERSATION(S, POST_ON_RECEIPT, RCB) (page 5.1-63). 
Call FSM_POST( POST_ON_RECEIPT) (page 5.1-66). 
Copy FILL and LENGTH parameters of the POST_ON_RECEIPT verb into RCB.POST_CONDITIONS. 
Call PROCESS _RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO SUSPEND) (page 5.1-47). 
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PREPARE_TO_RECEIVE_PROC 


FUNCTION: Handles the PREPARE_TO_RECEIVE verb. Depending on the TYPE of the PRE- 
PARE_TO_RECEIVE (FLUSH, CONFIRM or SYNC_LEVEL) and the SYNC_LEVEL of the con- 
versation (NONE, CONFIRM, or SYNCPT), the processing of the PREPARE_TO_RECEIVE 

is continued by other prec:cedures. 


INPUT: PREPARE_TO_RECEIVE verb parameters 


OUTPUT: If the PREPARE_TO_RECEIVE specifies TYPE = SYNC_LEVEL and the SYNC_LEVEL of 
the conversation is SYNCPT, the RETURN_CODE is set to OK and FSM_CONVERSATION 
(page 5.1-63) 1s updated to indicate that completion of the PREPARE_TO_RECEIVE 
processing 1s deferred until a FLUSH, CONFIRM, or SYNCPT verb is issued. Oth- 
erwise, processing 1s continued by other procedures. 


Referenced procedures, FSMs, and data structures: 


PREPARE_TO_RECEIVE_FLUSH_PROC page 5.1-43 
PREPARE_TO_RECEIVE_CONF IRM_PROC page 5.1-41 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
FSM_CONVERSATION page 5.1-63 
RCB page A-7 


Find the RCB for the conversation identified by the RESOURCE parameter. 
If data sent by TP is on a logical record boundary then 
Select based on one of the following conditions: 
When TYPE parameter = FLUSH or (TYPE parameter = SYNC_LEVEL and the 
conversation sync level of the conversation is = NONE) 
If executing FSM_CONVERSATION(S, PREPARE_TO_RECEIVE_FLUSH, RCB) (page 5.1-63). 
would cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
Call PREPARE_TO_RECEIVE_FLUSH_PROC( PREPARE_TO_RECEIVE parameters, RCB) 
(page 5.1-43). 
When TYPE parameter = CONFIRM | 
If executing FSM_CONVERSATION(S, PREPARE_TO_RECEIVE_CONFIRM, RCB) (page 5.1-63). 
would cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
If syne level of the conversation is CONFIRM or SYNCPT then 
Call PREPARE_TO_RECEIVE_CONFIRM_PROC( PREPARE_TO_RECEIVE parameters, RCB) 
(page 5.1-41). 
Else 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
When TYPE parameter = SYNC_LEVEL 
If executing FSM_CONVERSATION(S, PREPARE_TO_RECEIVE_DEFER, RCB) (page 5.1-63). 
would cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
If sync level of the conversation is SYNCPT then 
Call FSM_CONVERSATION(S, PREPARE_TO_RECEIVE_DEFER» RCB) (page 5.1-63). 
Copy LOCKS parameter into RCB. 
Set RETURN_CODE parameter to OK. 
Else 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
Else 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
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5. 1-20 


RECEIVE AND _WAIT_PROC 


FUNCTION: 


Handles the RECEIVE_AND_WAIT verb. 


If the resource specified in the RECEIVE_AND_WAIT is valid and the conversa- 
tion is in an appropriate state (i.e., RECEIVE_AND WAIT can be issued when the 
conversation is in the send or receive state), processing of the record con- 
tinues. PS first receives any records from RM and HS. Appropriate action is 
taken depending upon which, if any», record was received (as reflected by the 
state of FSM_ERROR_OR_FAILURE). 


RECEIVE_AND_ WAIT verb parameters 
See below. 


If a CONVERSATION_FAILURE has been received from the resources manager, PS 
returns to the transaction program after setting the RETURN_CODE parameter to 
RESOURCE_FAILURE. 


If the local LU has detected an error while attempting to allocate a session 
to this conversation, but PS has not yet had the opportunity to relay that 
information to the transaction program, it does so at this time by setting the 
RETURN_CODE parameter to reflect the type of allocation error. 


If a RECEIVE_ERROR record has been received from HS, PS sends a 
SEND_DATA_RECORD with the TYPE field set to PREPARE_TO_RCV_FLUSH to HS. (Any 
data in the RCB data buffer was purged when the RECEIVE ERROR record was 
received.) PS then waits for the expected FMH-7 error message to arrive. The 
RETURN_CODE parameter is set based on the sense data carried in the FMH-7. 


If the conversation is in the SEND state, PS sends a SEND_DATA_RECORD with the 
TYPE field set to PREPARE_TO_RCV_FLUSH to HS. All data in the RCB send buffer 
is placed in the SEND_DATA_RECORD. Regardless of the state of the conversa- 
tion, PS initializes the post conditions, waits for information to arrive to 
cause the conversation to become posted, and returns to the transaction pro- 
gram mith is received information. | 


Referenced procedures, FSMs; and data structures: 


PROCESS_RM_OR_HS_ TO_PS_ RECORDS page 5.1-47 
SEND_DATA_TO_HS_ PROC page 5.1-52 
POST_AND_ WAIT PROC page 5.1-40 
DEQUEUE_ FMH7_. PROC page 5.1-36 
PERFORM _RECEIVE_ PROCESSING page 5.1-39 
FSM_ CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RECEIVE _ERROR page A-12. 
SEND_DATA_RECORD page A-24 
RCB page A-7 


Find RCB for the resource identified in the RESOURCE parameter. 
If executing FSM_CONVERSATION(S,RECEIVE_AND WAIT, RCB) would 
cause a state-check (>) condition then 

Execute the corresponding output code in the FSM. 


Else 


Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO SUSPEND) (page 5.1-47). 


Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-65): 


When CONV_FAILURE_PROTOCOL_ERROR 

Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 

Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
When CONV_FAILURE_SON 

Set RETURN_CODE to RESOURCE_FAILURE_RETRY. 

Call FSM_CONVERSATION(R,» RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 


When ALLOCATE_FAILURE_RETRY | ALLOCATE_ FAILURE_NO_RETRY | SYNCLEVEL_NOT_SUPPORTED 


Set RETURN __ CODE to ALLOCATION_ERROR “with a subcode of 
ALLOCATION_FAILURE_RETRY, ALLOCATION_FAILURE_NO_RETRY,» or 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 

Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 
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When RCVD_ERROR 
If state of FSM_CONVERSATION = SEND then 
Set RCB.PS_TO_HS_RECORD type to PREPARE _TO_RCV_FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52)._ 
Call POST_AND_WAIT_PROC(RCB, LL, X'7FFF') (page 5.1-40). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON then 
Set RETURN_CODE to RESOURCE _FAILURE_RETRY. 
Else 
Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
Else 
Call DEQUEUE_FMH7_PROC(RECEIVE_AND_WAIT, RCB) (page 5.1-36). 
When NO_RQS 
Call FSM_CONVERSATION(S, RECEIVE_AND_WAIT, RCB) (page 5.1-63). 
If state of FSM_ERROR_OR_FAILURE is ALLOCATE_FAILURE_RETRY;, 
ALLOCATE_FAILURE_NO_RETRY, OR SYNCLEVEL_NOT_SUPPORTED then 
ALLOCATION_FAILURE_RETRY, ALLOCATION_FAILURE_NO_RETRY, or 
to SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 
Set RETURN_CODE to ALLOCATION_ERROR with a subcode of 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 
Else 
Call POST_AND_WAIT_PROC with RCB, FILL and LENGTH parameters (page 5.1-40). 
Call PERFORM_RECEIVE_PROCESSING(RCB, RECEIVE_AND_WAIT parameters) (page 5.1-39). 
If REQUEST_TO_SEND has been received but not reported to TP then 
Set REQUEST_TO_SEND_RECEIVED parameter to YES. 
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5.1-22 


FUNCTION: 


RECEIVE_IMMEDIATE_PROC 


This procedure performs the processing of the RECEIVE_ IMMEDIATE record. It 
receives any information available from the specified conversation, but does 
not wait for information to arrive. 


The procedure first receives any records from the RM_TO_PS and HS_TO_PS 
queues. Appropriate action is taken depending upon which, if any» record was 
received (as reflected by the state of FSM_ERROR_OR_FAILURE). 


RECEIVE_IMMEDIATE 


The RETURN_CODE and REQUEST_TO_SEND_RECEIVED fields of the RECEIVE_IMMEDIATE 
record are set to indicate the result of the verb. See below for additional 
output. | 


If a CONVERSATION_FAILURE has been received from the resources manager, PS 
returns to the transaction program after setting the RETURN_CODE field itn the 
RECEIVE IMMEDIATE to RESOURCE_FAILURE. 


If the local LU has detected an error while attempting to allocate a session 
to this conversation, but PS has not yet had the opportunity to relay that 
information to the transaction program, it does so at this time by setting the 
RETURN_CODE field of the RECEIVE_IMMEDIATE to reflect the type of allocation 
error. 


If a RECEIVE_ERROR has been received from HS, PS waits for the expected FMH-7 
error message to arrive. The RETURN_CODE field in the RECEIVE IMMEDIATE is 
set based on the sense data carried in the FMH-7. 


If no error or failure cendition has occurred, PS calls  PER- 
FORM_RECEIVE_PROCESSING (page 5.1-39), which checks to see if any information 
has arrived on the specified conversation and passes ine received information 


Cif any) to the SPAnSRe LION program. 


Referenced procedures, FSMs, and data structures: 


PROCESS _RM_OR_HS_TO_PS_RECORDS page 5.1-47 
POST_ AND _WAIT_ PROC page 5.1-40 
DEQUEUE_ FMH7_ PROC page 5.1-36 
PERFORM_RECEIVE_PROCESSING page 5.1-39 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RECEIVE _ ERROR page A-1l2 
RCB 


page A-7 


Find RCB for the resource identified in the RESOURCE parameter. 
If executing FSM_CONVERSATION(S, RECEIVE_IMMEDIATE, RCB) would 
cause a state-check (>) condition then 

Execute the corresponding output code in the FSM. 


Else 


Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 


When CONV_FAILURE_PROTOCOL_ ERROR 


Select based on the state of FSM_ERROR_OR_FAILURE (page §.1-65): 


Set 


RETURN_ CODE to RESOURCE_FAILURE_NO_RETRY. 


Call FSM_ CONVERSATION(R, RESOURCE_ FAILURE_RC, RCB) (page 5. 1-63). 
When CONV FAILURE_ SON 


Set 


RETURN _ CODE to RESOURCE_FAILURE_RETRY. 


Call FSM_CONVERSATION(R, RESOURCE_ FAILURE RC, RCB) (page 5.1-63). 
When ALLOCATE_FAILURE_RETRY | ALLOCATE_ FAILURE_NO_RETRY | SYNCLEVEL_NOT_SUPPORTED 


Set 


RETURN_ CODE to ALLOCATION_ERROR “with a subcode of 


ALLOCATION_FAILURE_RETRY; ALLOCATION_FAILURE_NO_RETRY; or 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 
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When RCVD_ERROR 
Call POST_AND_WAIT_PROC(RCB, LL» X'7FFF') (page 5.1-40). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON then 
Set RETURN_CODE to RESOURCE _FAILURE_RETRY. 
Else 
Set RETURN_CODE to RESOURCE _FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
Else 
Call DEQUEUE_FMH7_PROC(RECEIVE_AND WAIT, RCB) (page 5.1-36). 
When NO_RQS 
Call FSM_CONVERSATION(S, RECEIVE_IMMEDIATE, RCB) (page 5.1-63). 
Set RCB.POST_CONDITIONS .MAX_LENGTH to RECEIVE IMMEDIATE .MAX_LENGTH. 
Set RCB.POST_CONDITIONS.FILL to RECEIVE _IMMEDIATE.FILL. 
Call PERFORM_RECEIVE_PROCESSING(RCB, RECEIVE IMMEDIATE parameters) (page 5.1-39). 
If REQUEST_TO_SEND has been received but not reported to TP then 
Set REQUEST_TO_SEND_RECEIVED parameter to YES. 


REQUEST_TO_SEND_ PROC 


Handles REQUEST_TO_SEND verb processing. 


If the conversation is in the RECEIVE state, PS completes the processing of 
the REQUEST_TO_SEND record, as described below. 


REQUEST_TO_SEND verb parameters 
See below. 
Since REQUEST_TO_SENO does not have a RETURN_CODE parameter, error condi tions 


cannot be relayed to the transaction program at this time. PS rewembers the 
error (via FSM_ERROR_OR_FAILURE) and reports it to the transaction program at 


a later time (i.e., when a verb is issued by the transaction program that has 
a RETURN_CODE parameter). 


A REQUEST_TO_SEND record is not sent to HS if the partner transaction program 
has already issued a DEALLOCATE for the specified conversation. 


A REQUEST_TO_SEND record is not sent to HS if the partner transaction program 
has already issued a PREPARE_TO_RECEIVE for the specified conversation. 


If no records have been received from HS, or records have been received but do 
not indicate DEALLOCATE or PREPARE_TO_RCV, - this  precedure sends 
REQUEST_TO_SEND to HS and waits for the expected RSP_TO_REQUEST_TO_SEND before 
returning to the transaction program. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
PROCESS_RM_OR_HS_TO_PS_RECORDS page 5.1-47 
WAIT_FOR_RSP_TO_RQ_TO_SENO_PROC page 5.1-61 
FSM_CONVERSATION page 5.1-63 
RCB page A-7 
REQUEST_TO_SEND page A-24 


Find RCB for the resource identifier in REQUEST_TO_SEND. 
If executing FSM_CONVERSATION(S, REQUEST_TO_SEND, RCB) (page 5.1-63) mould 
cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 
If Change Direction (CD) indication has not been received from HS then 
Send a REQUEST_TO_SEND record to the HS. 
Call WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC(RCB) (page 5.1-61). 
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SEND_DATA_PROC 


FUNCTION: Handles the receipt of data from the transaction program. 


If the resource specified in the SEND_DATA is valid and the conversation is in 
the SEND state, processing of the record continues. PS first retrieves any 
records from RM and HS. Appropriate action is taken depending upon which, if 
any» record was received. 


INPUT: SEND_DATA verb parameters 
OUTPUT: - See below. 


NOTES: 1. Ifa CONVERSATION_FAILURE record has been received from the resources manager, 
PS returns to the transaction program after setting the RETURN_CODE parameter 
of the SEND_DATA to RESOURCE_FAILURE. 


2. If the local LU has detected an error while attempting to allocate a session 
to this conversation, but PS has not yet had the opportunity to relay that 
information to the transaction program, it does so at this time by setting the 
RETURN_CODE parameter of the SEND_DATA to reflect the type of allocation 
error. | 


3. If a RECEIVE_ERROR has been received from HS, PS sends a SEND_DATA with the 
TYPE field set to PREPARE_TO_RCV_FLUSH to HS. (Any data in the RCB data buff- 
_ -@r was purged when the RECEIVE_ERROR record was received.) PS then waits for 
the expected FMH-7 error message to arrive. The RETURN_CODE of the SEND_DATA 

is set based on the sense data carried in the FMH-7. 


G4. If no error or failure condition has occurred, PS scans the data in the passed 
SEND_DATA for logical record boundaries. (PS maintains in the RCB a count of 
the number of bytes of data remaining to be sent from the transaction program 
to finish the current logical record.) If there is enough data to send to HS, 
PS sends it. 


5. If no session has been allocated to this conversation (i.e., the ALLOCATE that 
allocated the conversation speci fied RETURN_CONTROL = 
DELAYED_ALLOCATION_PERMITTED), PS now requests a session from the resources 
manager. If, while attempting to allocate a session, the local LU detects an 
error, PS sets the RETURN_CODE field in the SEND_DATA to reflect the type of 
allocation error and returns control to the transaction program. 


Referenced procedures, FSMs, and data structures: 


PROCESS_RM_OR_HS_TO_PS_RECORDS page 5.1-47 
SEND_DATA_TO_HS_PROC page 5.1-52 
POST_AND_WAIT_PROC page 5.1-40 
DEQUEVE_FMH7_PROC page 5.1-36 
SEND_DATA_BUFFER_MANAGEMENT page 5.1-51 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
FSM_CONVERSATION | | page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 

CONVERSATION_FAILURE | page A-32 

RECEIVE ERROR page A-12 


Find the RCB for the resource identified in the RESOURCE parameter. 
If executing FSM_CONVERSATION(S, SEND_DATA, RCB) (page 5.1-63) 
would cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else ar | 
Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 
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Select based on state of FSM_ERROR_OR_FAILURE (page 5.1-65): 
When CONV_FAILURE_SON (see Note 1) 
Set RETURN_CODE to RESOURCE_FAILURE_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
When CONV_FAILURE_PROTOCOL_ERROR (see Note 1) 
Set RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
When ALLOCATE_FAILURE_RETRY, ALLOCATE_FAILURE_NO_RETRY,» or 
SYNCLEVEL_NOT_SUPPORTED (see Note 2) 
Set RETURN_CODE to ALLOCATION_ERROR with a subcode of 
ALLOCATION _FAILURE_RETRY, ALLOCATION _FAILURE_NO_RETRY, or 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC,» RCB) (page 5.1-63). 
When RCVD_ERROR (see Note 3) 
Set RCB.PS_TO_HS_RECORD type to PREPARE_TO_RCV_FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
Call POST_AND_WAIT_PROC(RCB, LL, X'7FFF') (page 5.1-40). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON then 
Set RETURN_CODE to RESOURCE _FAILURE_RETRY. 
Else 
Set RETURN_CODE to RESOURCE _FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
Else 
Call DEQUEUE_FMH7_PROC(SEND DATA, RCB) (page 5.1-36). 
When NO_RQS 
Perform the LL processing (see Note 4). 
If LL is not valid (i.e., values X'0000', X'8000', and X'8001' are not valid; 
X'0001' is valid only for PS headers--see Appendix H) then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 
Call SEND_DATA_BUFFER_MANAGEMENT (page 5.1-51) 
with the first LENGTH bytes of the DATA (see SEND_DATA verb parameters) and RCB. 


If the state of FSM_ERROR_OR_FAILURE (page 5.1-65) 
is ALLOCATE_FAILURE_RETRY, ALLOCATE_FAILURE_NO_RETRY, or 
SYNCLEVEL_NOT_SUPPORTED (see Note 5) then 
Set RETURN_CODE to ALLOCATION_ERROR with a subcode of 
ALLOCATION_FAILURE_RETRY, ALLOCATION_FAILURE_NO_RETRY,» or 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 
Else | 
Set RETURN_CODE to OK. 


If REQUEST_TO_SEND has been received but not reported to TP then 
Set REQUEST_TO_SEND_RECEIVED return parameter to YES. 
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SEND_ERROR_PROC 


— 


FUNCTION: 


INPUT: 
OUTPUT: 


NOTES: 1. 


Handles the SEND_ERROR verb processing. 


If the resource specified in the SEND_ERROR is valid and the conversation is 
in an appropriate state, processing of the SEND_ERROR continues. PS first 
retrieves any records from RM and HS. Appropriate action is taken depending 
upon which, if anys record was received (as reflected by the state of 
FSM_ERROR_OR_FAILURE). 


SEND_ERROR verb parameters 
See below. 


If a CONVERSATION_FAILURE has’ been received from the resources manager, PS 
returns to the transaction program after setting the RETURN_CODE parameter of 
the SEND_ERROR to RESOURCE_FAILURE. 


If the local LU has detected an error while attempting to allocate a session 
to this conversation, but PS has not yet had the opportunity to relay that 
information to the transaction program, it does so at this time by setting the 
RETURN_CODE parameter of the SEND_ERROR to reflect the type of allocation 
error. 


If RECEIVE_ERROR has been received from HS or no error records have been 
received, further processing of the SEND_ERROR is performed, depending upon 
the state of the conversation. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
HS page 6.0-3 
PROCESS_RM_OR_HS_TO_PS_RECORDS page 5.1-47 
SEND_ERROR_IN_SEND_STATE page 5.1-55 
SEND_ERROR_DONE_ PROC page 5.1-53 
SEND_ERROR_IN_RECEIVE_STATE page 5.1-54¢ 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 
BUFFER_ELEMENT page A-8 
SEND_ERROR page A-24 
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a state-check (>) condition then 
e corresponding output code in the FSM. 


SS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 


ed on state of FSM_ERROR_OR_FAILURE: 

NV_FAILURE_SON (see Note 1) 

RETURN_CODE of SEND_ERROR verb to RESOURCE_FAILURE_RETRY. 
FSM_CONVERSATION(R» RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 

NV_FAILURE_PROTOCOL_ERROR (see Note 1) 

RETURN_CODE of SEND_ERROR verb to RESOURCE_FAILURE_NO_RETRY. 
FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 


When ALLOCATE_FAILURE_RETRY, ALLOCATE_FAILURE_NO_RETRY>» or 


SYNCLE 
Set 


VEL_NOT_SUPPORTED (see Note 2) 
RETURN_CODE of SEND_ERROR verb to ALLOCATION_ERROR with a subcode of 


ALLOCATION _FAILURE_RETRY, ALLOCATION_FAILURE_NO_RETRY» or 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 
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SEND_ERROR_PROC 
When NO_RQS or RCVD_ERROR (see Note 3) 


Select based on the state of FSM_CONVERSATION (page 5.1-63): 
When SEND 
Call SEND_ERROR_IN_SEND_STATE(SEND_ERROR parameters, RCB) (page 5.1-55). 
When RCVD_CONFIRM;, RCVD_CONFIRM_SEND, or RCVD_CONFIRM_DEALL 
Send SEND_ERROR record to HS. 
Call FSM_CONVERSATION(S, SEND_ERROR, RCB) (page 5.1-63). 
Call SEND_ERROR_DONE_PROC(SEND_ERROR,» RCB) (page 5.1-53). 
When RCV 
Call SEND_ERROR_IN_RECEIVE_STATE(SEND_ERROR parameters, RCB) (page 5.1-54). 
Remove all entries in the RCB.HS_TO_PS_BUFFER_LIST. 


If REQUEST_TO_SEND has been received but not reported to TP then 
Set REQUEST_TO_SEND_RECEIVED parameter of SEND_ERROR verb to YES. 


TEST_PROC 


Performs the processing of a TEST record. 


The procedure first receives any records from RM and HS. It then tests wheth- 
er the conversation has been posted or whether REQUEST_TO_SEND notification 
has been received from the remote transaction. The RETURN_CODE field of TEST 


records the result of the test. 


TEST record 


The RETURN_CODE field of TEST records the result of the test. 


Referenced procedures, FSMs, and data structures: 


PROCESS _RM_OR_HS_TO_PS_RECORDS page 5.1-47 
POST_AND_WAIT_PROC page 5.1-40 
DEQUEVE_FMH7_PROC page 5.1-36 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
FSM_POST page 5.1-66 
TEST page 5.1-67 
RCB page A-7 

BUFFER_ELEMENT page A-8 


Find the RCB for the resource identified in the RESOURCE field of the TEST record. 
If executing FSM_CONVERSATION(S,:- TEST, RCB) (page 5.1-63) 
would cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 
Select based on test type (recorded in TEST.TEST): 
When POSTED 
If state of FSM_POST = RESET then 
Set RETURN_CODE of TEST to POSTING_NOT_ACTIVE. 
Else 
Select based on the state of FSM_ERROR_OR_FAILURE: 
When CONV_FAILURE_SON 
Set RETURN_CODE of TEST to RESOURCE _FAILURE_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
When CONV _FAILURE_PROTOCOL_ERROR 
Set RETURN_CODE of TEST to RESOURCE _FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE _FAILURE_RC, RCB) (page 5.1-63). 
When ALLOCATE_FAILURE RETRY, ALLOCATE_FAILURE_NO_RETRY» or 
SYNCLEVEL_NOT_SUPPORTED 
Set RETURN_CODE of TEST to ALLOCATION_ERROR with a subcode of 
ALLOCATION _FAILURE_RETRY, ALLOCATION_FAILURE_NO_RETRY, or: 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU respectively. 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 
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TEST_PROC 


5.1-28 


When RCVD_ERROR 
Call POST_AND_WAIT_PROC(RCB, LL, X'77FF') (page 5.1-40). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON then 
Set RETURN_CODE of TEST to RESOURCE_FAILURE_RETRY. 
Else 
Set RETURN_CODE of TEST to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
Else 
Call DEQUEVE_FMH7_PROC( TEST, RCB) (page 5.1-36). 
When NO_RQS 
Select on state of FSM_POST: 
When PEND_POSTED. 
Set RETURN_CODE of TEST to UNSUCCESSFUL. 
When POSTED . 
Set RETURN_CODE of TEST to OK with a subcode of NOT_DATA 
or DATA as the RCB.HS_TO_PS_BUFFER_LIST is or is not empty. 


Call FSM_CONVERSATION(S, TEST, RCB) (page 5.1-63). 
Call FSM_POST(TEST) (page 5.1-66). 
When REQUEST_TO_SEND_RECEIVED 

If REQUEST_TO_ SEND has been received but not reported to TP then 
Set RETURN_CODE of TEST to OK. 
Record as reported to TP the REQUEST_TO_SEND. 

Else 
Set RETURN CODE to UNSUCCESSFUL. 
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LOW-LEVEL PROCEDURES 


COMPLETE_CONFIRM_PROC 


FUNCTION: Completes the processing of a CONFIRM verb. 


INPUT: 


OUTPUT: 


NOTES: 


Reference 


Select ba 
When S$ 
Set 


It is called by CONFIRM_PROC (page 5.1-12) when there are no error or failure 
conditions indicated by FSM_ERROR_OR_FAILURE (page 5.1-65). The action of 
this procedure is dependent on the state of the conversation, as described 
below. 


CONFIRM parameters and the RCB corresponding to the resource specified in the 
CONFIRM verb 


See below. 


1. If FSM_CONVERSATION is in the SEND state, a SEND_DATA_RECORD with TYPE field 
set to CONFIRM is sent to HS. 


2. If FSM_CONVERSATION is in the PREPARE_TO_RECEIVE_DEFER state; a 
SEND_DATA_RECORD with TYPE field set to PREPARE_TO_RCV_CONFIRM is sent to HS. 


3. If FSM_CONVERSATION is in the DEALLOCATE_DEFER state, a SEND_DATA_RECORD with 
TYPE field set to DEALLOCATE_CONFIRM is sent to HS. 


4. If no session has been allocated to this conversation (i.e., the ALLOCATE verb 
issued to allocate the conversation = specified RETURN_CONTROL = 
DELAYED_ALLOCATION_PERMITTED), P& now reques‘s = session from the resources 
manager. If, while attempting to allocate a session, the local LU detects an 
error, PS sets the RETURN_CODE parameter of the CONFIRM to reflect the type of 
allocatior, error and returns control to the transaction program. 


d procedures, FSMs, and data structures: 

SEND_DATA_TO_HS_PROC page 5.1-52 
WAIT_FOR_CONFIRMED_PROC page 5.1-59 
FSM_CONVERSATICN page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 
SEND_DATA_RECORD page A-24 


sed on the state of FSM_CONVERSATION (page 5.1-63): 
END (see Note 1.) 
RCB.PS_TO_HS_RECORD.TYPE to CONFIRM. 


When PREP_TO_RCV_DEFER (see Note 2) 


Set 

PR 
When D 
Set 


RCB.PS_TO_HS_RECORD.TYPE to PREPARE_TO_RCV_CONFIRM_SHORT or 
EPARE_TO_RCV_CONFIRM_LONG as indicated by RCB.LOCKS. 
EALL_DEFER (see Note 3) 

RCB.PS_TO_HS_RECORD.TYPE to DEALLOCATE_CONFIRM. 


Call FSM_CONVERSATION(S, CONFIRM, RCB) (page 5.1-63). 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 


If state of FSM_ERROR_OR_FAILURE is ALLOCATE_FAILURE_RETRY, 
ALLOCATE_FAILURE_NO_RETRY, OR SYNCLEVEL_NOT_SUPPORTED (see Note 4) then 
Set RETURN_CODE to ALLOCATION_ERROR with a subcode of 
ALLOCATION_FAILURE_RETRY, ALLOCATION_FAILURE_NO_RETRY, or 
to SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 


Else 


Call WAIT_FOR_CONFIRMED_PROC(CONFIRM parameters, RCB) (page 5.1-59). 
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COMPLETE_DEALLOCATE_ABEND_PROC 


COMPLETE_DEALLOCATE_ABEND_PROC 


Completes the processing of a DEALLOCATE verb that specifies TYPE = ABEND. 


PS creates an FMH-7 and places it in the RCB send buffer. The FMH-7 carries 
sense data indicating DEALLOCATE_ABEND. If there is any log data associated 
with the DEALLOCATE, PS creates an Error Log GDS variable (see “Appendix H. FM 
Header and LU Services Commands'') and places it in the RCB buffer to be sent 
to the partner LU. PS also places the 6DS variable (minus the LL and GOS ID 
fields) in the local LU's system error log. PS then sends a SEND_DATA_RECORD, 
containing the FMH-7 and optional Error Log 6DS variable, to HS. 


DEALLOCATE verb parameters and the RCB corresponding to the resource speci fied 
in the DEALLOCATE 


SEND_DATA to HS. Any log data supplied with the DEALLOCATE is logged. 


If no session has been allocated to this conversation (i.e., the ALLOCATE that 
allocated the conversation speci fied RETURN_CONTROL = 
DELAYED_ALLOCATION_PERMITTED), PS now requests a session from the resources 
manager. If, while attempting to allocate a session, the local LU detects an 
error, PS sets the RETURN_CODE parameter in the DEALLOCATE to reflect the type 
of allocation error and returns control to the transaction program. 


Referenced procedures, FSMs, and data structures: 


SEND_DATA_TO_HS_PROC page 5.1-52 
SEND_DATA_BUFFER_MANAGEMENT page 5.1i-51 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FATLURE page 5.1-65 
RCB& page A-7 
SEND_DATA_RECORD page A-24 


Set SENSE_DATA based on the DEALLOCATE type as follows: 

set to X'08640000" if ABEND_PROG, to X'08640001' if ABEND_SVC, or 
to X'8640002'if ABEND_TIMER. 

Set CONTINUE to true. 


If state of FSM_CONVERSATION (page 5.1-63) 
is SEND, PREP_TO_RCV_DEFER, or DEALL_DEFER 

and RCB.PS_TO_HS_RECORD.SEND_PARM.DATA is not null then 
Set RCB.PS_TO_HS_RECORD.TYPE to FLUSH._ 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) 

is ALLOCATE_FAILURE_RETRY, ALLOCATE_FAILURE_NO_RETRY, or SYNCLEVEL_NOT_SUPPORTED then 
Set CONTINUE to false. 


If CONTINUE then 
If LOG_DATA parameter has been supplied then 
Create FMH-7 with log data indicator and SENSE_DATA. 
Set RCB.HS_TO_PS_RECORD.DATA to this FMH-7. 
Create Error Log GDS variable and concatenate it to 
RCB.PS_TO_HS_ RECORD .DATA. 
Log it in the system error log. 


Else 
Create FMH-7 with SENSE_DATA but no log data. 
Set RCB.HS_TO_PS_RECORD.DATA to this FMH-7. 
Call SEND_DATA_BUFFER_MANAGEMENT(null data, RCB) (page 5.1-51). 
Set RCB_PS_TO_HS record type to DEALLOCATE_FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
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CONVERSATION_FAILURE_PROC 


CONVERSATION. FAILURE_PROC 


FUNCTION: Processes CONVERSATION_FAILURE records. 


INPUT : A CONVERSATION_FAILURE record 


OUTPUT: FSM_ERROR_OR_FAILURE is set to the appropriate state. PS remembers the con- 
versation failure until that information can be relayed to the transaction 
program. 


Referenced procedures, FSMs, and data structures: 


FSM_ERROR_OR_FAILURE page 5.1-65 
FSM_POST page 5.1-66 
CONVERSATION_FAILURE page A-32 
RCB page A-7 


If the RCB for the CONVERSATION_FAILURE record is found, then 


If CONVERSATION_FAILURE.REASON = PROTOCOL_VIOLATION then 
Call FSM_ERROR_OR_FAILURE (page 5.1-65) and 
pass it a CONV_FAIL_PROTOCOL signal. 
Else 
Call FSM_ERROR_OR_FAILURE (page 5.1-65) 
and pass it a CONV_FAIL_SON signal. 


If state of FSM_POST is PEND_POSTED then 
Call FSM_POST(POST) (page 5.1-66). 
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DEALLOCATE_ABEND_PROC 


DEALLOCATE_ABEND_PROC 


FUNCTION: Invoked when the TYPE parameter of DEALLOCATE verb is ABEND_PROG, ABEND_SVC, 
or ABEND_TIMER. ; 


PS first receives any records from RM and HS. Appropriate action is taken 
depending upon which, if any» record was received and upon the state of the 
conversation. The state of the conversation and the information in the 
HS_TO_PS_BUFFER_LIST determine whether or not a SEND_ERROR record is sent to 
HS prior to sending the FMH-7 that is created as a result of the DEALLOCATE 
(TYPE = ABEND_*). Receipt of certain types of information (e.g.», notification 
that the conversation has been deallocated by the partner transaction program) 
causes PS to return to the transaction program without taking any action. 


INPUT: DEALLOCATE verb parameters and the RCB corresponding to the resource specified 
in the DEALLOCATE 


OUTPUT: Depending upon the state of the conversation and the information contained in 
the HS_TO_PS_BUFFER_LIST, an FMH-7 (possibly preceded by a SEND_ERROR record) 
is created and sent to HS, or no output is created. All elements are purged 
from the HS_TO_PS_BUFFER_LIST before returning to the transaction program. 


Referenced procedures, FSMs, and data structures: : 
PS ~~ < | page 


5.0-5 
HS page 6.0-3 
PROCESS_RM_OR_HS_TO_PS_RECORDS | | page 5.1-47 
WAIT _FOR_SEND_ERROR_DONE_ PROC | | page 5.1-62 
COMPLETE_DEALLOCATE_ABEND_PROC page 5.1-30 
FSM_CONVERSATION | | 7 page 5.1-63 
FSM_ERROR_OR_FAILURE | | page 5.1-65 
RCB page A-7 
SEND_ERROR 3 : | | page A-24¢ 


Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 


If the state of FSM_ERROR_OR_ FAILURE (page 5. 1-65) is 
NO_RQS or RCVD_ERROR then 


Select based on the state of FSM_ CONVERSATION (page 5.1-63): 
When RCV | 
If the first entry of RCB.HS_TO_PS _BUFFER_LIST is not DEALLOCATE_ FLUSH then 
Send SEND_ERROR record to HS. 
Call WAIT_FOR_SEND_ERROR_DONE_PROC(DEALLOCATE parameters, RCB) 
(page 5.1-62). 
When RCVD_CONFIRM | RCVD_CONFIRM_SEND | RCVD_CONFIRM_DEALL 
Send SEND_ERROR record to HS. 
Call COMPLETE_DEALLOCATE_ABEND_PROC(DEALLOCATE parameters, RCB) 
(page 5.1-30). 
When SEND | PREP_TO_RCV_DEFER | DEALL_DEFER 
Call COMPLETE_DEALLOCATE_ABEND_PROC(DEALLOCATE parameters, RCB) 
(page 5.1-30). 


Purge all buffers in HS_TO_PS_BUFFER_LIST. 


Set RETURN_CODE to OK. 
Call FSM_CONVERSATION(S, DEALLOCATE_ABEND) (page 5.1-63). 
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DEALLOCATE_CONFIRM_PROC 
DEALLOCATE_CONFIRM_PROC 


FUNCTION: Invoked when DEALLOCATE TYPE(SYNC_LEVEL) is issued for a conversation whose 
SYNC_LEVEL is CONFIRM. 


PS first retrieves any records from HS. Appropriate action is taken depending 
upon which, if any» record was received. 


INPUT: DEALLOCATE verb parameters and the RCB corresponding to the resource specified 
in the DEALLOCATE 


OUTPUT: See below. 


NOTES: If a CONVERSATION_FAILURE has been received from the resources manager, PS 
returns to the transaction program after setting the RETURN_CODE parameter of 
the DEALLOCATE to RESOURCE_FAILURE. 


If the local LU has detected an error while attempting to allocate a session 
to this conversation, but PS has not yet had the opportunity to relay that 
information to the transaction program, it does so at this time by setting the 
RETURN_CODE parameter of the DEALLOCATE to reflect the type of allocation 
error. 


If a RECEIVE_ERROR has been received from HS, PS sends a SEND_DATA_RECORD with 
the TYPE field set to PREPARE _TO_RCV_FLUSH to HS. (Any data in the RCB send 
buffer was purged when the RECEIVE_ERROR_RECORD was received.) PS then waits 
for the expected FMH-7 error message to arrive. The RETURN_CODE parameter of 
the DEALLOCATE is set based on the sense data carried in the FMH-7. 


If no error or failure condition has occurred, PS sends a SEND_DATA_RECORD 
with the TYPE field set to DEALLOCATE_CONFIRM to HS. 


If no session has been allocated to this conversation (i.e., the ALLOCATE that 
allocated the conversation speci fied RETURN_CONTROL = 
DELAYED_ALLOCATION_PERMITTED), PS now requests a session from the resources 
manager. If, while attempting to allocate a session, the local LU detects an 
error, PS sets the RETURN_CODE parameter of the DEALLOCATE to reflect the type 
of allocation error and returns control to the transaction program. 


Referenced procedures, FSMs, and data structures: 


PROCESS_RM_OR_HS_TO_PS_RECORDS page 5.1-47 
SEND_DATA_TO_HS_PROC page 5.1-52 
POST_AND_WAIT_PROC . page 5.1-40 
DEQUEUVE_FMH7_PROC page 5.1-36 
WAIT_FOR_CONF IRMED_ PROC page 5.1-59 
DEALLOCATION_CLEANUP_PROC | page 5.0-13 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 

SEND_DATA_RECORD page A-24 


If data sent by TP is not at a logical record boundary then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 


Else 
Call FSM_CONVERSATION(S, DEALLOCATE_CONFIRM, RCB) (page 5.1-63). 
Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 


Select based on the state of FSM_ERROR_OR_FAILURE (see Note 1): 

When CONV_FAILURE_PROTOCOL_ERROR 

Set RETURN_CODE of DEALLOCATE to RESOURCE_FAILURE_NO_RETRY. 

Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
When CONV_FAILURE_SON 

Set RETURN_CODE of DEALLOCATE to RESOURCE_FAILURE_RETRY. 

Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
When ALLOCATE_FAILURE_RETRY, ALLOCATE_FAILURE_NO_RETRY, or 
SYNCLEVEL_NOT_SUPPORTED (see Note 2) 

Set RETURN_CODE of DEALLOCATE to ALLOCATION_ERROR with a subcode of 
ALLOCATION_FAILURE_RETRY, ALLOCATION_FAILURE_NO_RETRY,» or 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 

Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 
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DEALLOCATE_CONFIRM_PROC 


When RCVD_ERROR (see Note 3) 
— Set RCB.PS_TO_HS_RECORD type to PREPARE_TO_RCV_FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
Call FOST_ AND_WAIT_PROC(RCB, LL, X'7FFF') to post the resource 
when the whole FMH7 is received (page 5.1-40). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON then 
Set RETURN_CODE of DEALLOCATE to RESOURCE_FAILURE_RETRY. 
Else 
Set RETURN_CODE of DEALLOCATE to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
Else 
Call DEQUEUE_FMH7_PROC(RECEIVE _ANO_WAIT, RCB) (page 5.1-36). 
When NO_RQ@S (see Note 4) 
Set RCB.PS_TO_HS RECORD type to PREPARE_TO_RCV_FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 


If state of FSM_ERROR_OR_FAILURE is ALLOCATE_FAILURE_RETRY, 
ALLOCATE_FAILURE_NO_RETRY, or SYNCLEVEL_NOT_SUPPORTED then 
Set RETURN. CODE of DEALLOCATE to ALLOCATION_ERROR with a subcode of 
ALLOCATION_FAILURE_RETRY, ALLOCATION, FATLURE_ NO_RETRY, or 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 
Call FSM | CONVERSATION(R, ALLOCATION. ERROR_RC, RCB) (page 5. 1-63). 
Call WAIT_FOR_CONFIRMED _PROC( DEALLOCATE parameters, RCB) (page 5.1~59). 
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DEALLOCATE_FLUSH_PROC 
DEALLOCATE_FLUSH_ PROC 


FUNCTION: Invoked when a DEALLOCATE is received that specifies TYPE = FLUSH, or TYPE = 
SYNC_LEVEL and the SYNC_LEVEL of the conversation is NONE. 


After checking that the data for the conversation is on a logical record 
boundary, the procedure accepts any records from RM and HS. Appropriate 
action is taken, depending upon which, if any, record was received (as 
reflected by the state of FSM_ERROR_OR_FAILURE). 


INPUT: DEALLOCATE verb parauweters and the RCB corresponding to the resource speci fied 
in the DEALLOCATE 


OUTPUT: See below. 
NOTES: 13. If a RECEIVE_ERROR was received from HS, or no error records have been 
received, PS sends any data remaining in the RCB send buffer to HS with the 
TYPE field of the SEND_DATA_RECORD set to ODEALLOCATE_FLUSH. (If a 
RECEIVE_ERROR was received, any data in PS's buffer has already been purged. ) 
2. If CONVERSATION_FAILURE record has been received from RM, or if an allocation 
error has been detected by the local LU, no further records are sent to HS. 


Referenced procedures, FSMs, and data structures: 


PROCESS _RM_OR_HS_TO_PS_RECORDS page 5.1-47 
SEND_DATA_TO_HS_ PROC page 5.1~52 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 
SEND_DATA_RECORD page A-24 
RECEIVE_ERROR page A-12 


If the data sent by TP is not at a logical record boundary then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13). 


Else 

Call PROCESS _RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 

If state of FSM_ERROR_OR_ FAILURE is RCVD_ERROR or NO_RQS (see Note 1) then 
Set RCB.PS_TO_HS record type to DEALLOCATE_FLUSH. 
Call SENO_DATA_TO_HS_PROC(RCB) (page 5.1-52). 

Else (see Note 2) 
Do nothing. 

Set RETURN_CODE of DEALLOCATE to OK. 

Call FSM_CONVERSATION(S, DEALLOCATE_FLUSH, RCB) (page 5.1-63). 


Chapter 5.1. Presentation Services-~Conversation Verbs 5.1-35 


- DEQUEUE_FMH7_PROC 


DEQUEUE_FMH7_ PROC 


Invoked upon receipt of a RECEIVE ERROR from HS. The next element expected in 
the HS_TO_PS_BUFFER_LIST is an FMH-7 buffer element. If the next element in 
the buffer is an FMH-7, it is removed from the buffer and processed (the 
RETURN_CODE parameter of the passed verb parameters is set based upon the . 
sense data carried in the FMH-7 buffer element). If the next element is not 
an FMH-7 buffer element, the partner LU has violated the protocol and, as an. 
implementation-dependent option, the session over which the protocol violation 
occurred is deactivated. 


The transaction program verb parameters currently being processed and the RCB 
corresponding to the resource specified in parameters of the verb 


The RETURN_CODE parameter is set to reflect the sense data carried in the 
FMH-7 buffer element. 


Referenced procedures, FSMs, and data structures: 


PROCESS _FMH7_PROC | page 5.1+46 
PS_PROTOCOL_ERROR | page 5.0-15 
{ 5M_POST 3 page 5.1-66 
RCB page A-7 
BUFFER_ ELEMENT page A-8 


call FSM_POST(RECEIVE_ IMMEDIATE ) (page 5.1-66). 
If first entry in RCB. HS_TO_PS_BUFFER_LIST is FMH-7 then 
Remove the first entry of RCB. HS_ TO_ PS_BUFFER_LIST. 
Call PROCESS _FMH7_PROCC(RCB, BUFFER_ELEMENT DATA; TP verb parameters ) 
(page 5.1-46). 
Set RCB.RECEIVE_LL_REMAINDER to 0. 
Else (as an imp lementati on-dependent option) 
Call PS_PROTOCOL_ERROR with X'1008201D' for Request Error; 
FMH-7, and Associated Data Mismatch (page 5.0-15). 
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GET_END_CHAIN_FROM_HS 
GET_END_CHAIN_FROM_HS 


FUNCTION: Invoked after PS sends a SEND_ERROR record to HS (as a result of a SEND_ERROR 
or DEALLOCATE (TYPE = ABEND_PROG, ABEND SVC, ABEND_TIMER) issued for the con- 
versation while it is in the receive state). This procedure waits for a 
RECEIVE_DATA whose TYPE field indicates EC to arrive from HS. TYPE values 
that indicate EC are CONFIRM, PREPARE_TO_RCV_CONFIRM, PREPARE_TO_RCV_FLUSH, 
DEALLOCATE_CONFIRM; and DEALLOCATE_FLUSH. 


INPUT: The RCB corresponding to the conversation for which the EC is desired 


OUTPUT: See below. 


NOTES: 1. If a REQUEST_TO_SEND record is received, PS stores that information in the RCB 
to be relayed to the transaction program at a later time, and continues to 
wait for the EC. 


If a RECEIVE_ERROR record is received, no action is taken. PS continues to 
wait for the EC to arrive. This situation occurs if, immediately prior to 
issuing the SEND_ERROR or DEALLOCATE (TYPE = ABEND_*), the transaction program 
issued a PREPARE_TO_RECEIVE (TYPE = FLUSH) or PREPARE_TO_RECEIVE (TYPE = 
SYNC_LEVEL) and the SYNC_LEVEL of the conversation is NONE, and the partner 
transaction program (while still in RECEIVE state) issues a SEND_ERROR or 
DEALLOCATE (TYPE = ABEND_*). 


When PS sends SEND_ERROR to HS, it begins to purge any data it receives from 
HS until a record indicating EC is received. 


Referenced procedures, FSMs, and data structures: 


RECEIVE _RM_OR_HS_TO_PS_RECORD page 5.1-51 
CONVERSATION_FAILURE_PROC page 5.1-31 
RCB | . page A-7 
BUFFER_ELEMENT page A-8 
RECEIVE _DATA page A-12 


If the type of BUFFER_ELEMENT in the RCB.HS_TO_PS_BUFFER_LIST is 
CONFIRM, PREPARE_TO_RCV_CONFIRM, PREPARE_TO_RCV_FLUSH, 
DEALLOCATE_CONFIRM, or DEALLOCATE_FLUSH thai 

Set EC_HAS ARRIVED to true. 

Else 

Set EC_HAS ARRIVED to false. 


poet NOT_CONVERSATION_FAILURE to true. 
Do while EC_HAS_ARRIVED not true and NOT_CONVERSATION_FAILURE is true: 
Call RECEIVE_RM_OR_HS_TO_PS_RECORD(RCB.RCB_IS, SUSPEND) to receive 
record (page 5.1-51) to receive RECORD. 
If RECORD arrived frcem RM then 
Call CONVERSATION_FAILURE_PROC with RECORD (page 5.1-31). 
Set NOT_CONVERSATION_FAILURE to false. 
If RECORD arrived from HS then 
Select based on the RECORD type received: 
When REQUEST_TO_SEND (see Note 1) 
Set RCB.RQ_TO_SEND_RCVD to YES. 
When RECEIVE_ERROR (see Note 2) 
Do nothing. 
When RECEIVE_DATA (see Note 3) 
If RECEIVE DATA type is CONFIRM, PREPARE_TO_RCV_CONFIRM, 
PREPARE_TO_RCV_FLUSH, DEALLOCATE_CONFIRM, or DEALLOCATE_FLUSH then 
Enqueue RECORD to RCB.HS_TO_PS_BUFFER_LIST. 
Set EC_HAS ARRIVED to false. 
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OBTAIN_SESSION_PROC 


FUNCTION: Handles the acquisition of a session for use by a conversation resource. 


This procedure sends a GET_SESSION Feces to the resources manager and waits 
for a SESSION_ALLOCATED reply. 


PS can instruct RM to send the RCB send buffer containing the FMH-5 (Attach) 
for this conversation to HS when both of the following conditions hold: 


® The transaction program has issued DEALLOCATE, PREPARE_TO_RECEIVE, and/or 
CONFIRM. | : 

® No data has as yet been sent to HS (i.e., the data sent by the transaction 
program to PS has not been of sufficient quantity to cause PS's Bend buf f- 
er to overflow). 


This situation can occur only if the ALLOCATE that caused this conversation to 
be initiated specified RETURN_CONTROL = DELAYED_ALLOCATION_PERMITTED. 


If the allocation of a session fails, the reason is saved’ in 
FSM_ERROR_OR_FAILURE. PS informs the transaction program at the earliest 
opportunity of the failure with an allocation error return code of the appro- 
priate kind. | 


The RCB corresponding to the conversation that is to use the obtained session, 
and an ATTACH/NO_ATTACH indicator (specifying whether RM is to send the send 
buffer containing the Attach to HS as it acquires the session) are passed as 
parameters to this procedure. SESSION_ALLOCATED is received from RM. 


OUTPUT : GET_SESSION is sent to RM 


Referenced procedures, FSMs, and data structures: 


WAIT_FOR_RM_REPLY | page 5.1-60 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 
GET_SESSION page A-26 
SESSION_ALLOCATED page A-33 


Copy TCB_ID and RCB_ID from RCB into GET_SESSION record. 
Set GET_SESSION.BID_INDICATOR to ATTACH or NO_ATTACH to agree with the input indicator. 
Send GET_SESSION request to RM. 
Call WAIT_FOR_RM_REPLY (page 5.1-60) to receive SESSION_ALLOCATED. 
Select based on SESSION_ALLOCATED.RETURN_CODE: 
When OK 
If the security level of RCB.SECURITY_SELECT has been downgraded to NONE then 
Rebuild the Attach omitting the obsolete security information. 
When UNSUCCESSFUL_NO_RETRY 
Call FSM_ERROR_OR_FAILURE (page 5.1-65) 
and pass it an ALLOCATE_FAIL_NO_RETRY signal. 
When SYNC_LEVEL_NOT_SUPPORTED 
Call FSM_ERROR_OR_FAILURE (page 5.1-65) 
and pass it a SYNCLEVEL_NOT_SUPPTD signal. 
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PERFORM_RECEIVE_PROCESSING 


Checks the appropriate HS_TO_PS_BUFFER_LIST receive buffer to see if any 
information has arrived for the conversation specified in the passed RECEIVE 
verb parameters and, if so, updates the verb parameters to reflect that infor- 
mation. Examples of the type of information that can be received include a 
request for confirmation, notification that the partner transaction program 
has deallocated the conversation, and conversation data. 


If no information has been received for the specified conversation, the 
RETURN_CODE parameter is set to UNSUCCESSFUL and control is returned to the 
calling procedure. 


The entry in the RCB_LIST corresponding to the resource specified in the verb 
parameters, and RECEIVE verb parameters 


Various parameters are updated, depending on the type of information contained 
in the recetve buffer. The information is removed from the 
HS_TO_PS_BUFFER_LIST after being placed in RECEIVE VERB. 


PS performs an optional receive check to determine if the partner LU has vio- 
lated PS protocols by allowing the partner transaction program to invalidly 
truncate the logical record the program was in the process of sending (i.e., 
the partner transaction program issued a verb, such as CONFIRM, before com- 
pleting the current logical record). Only an FMH-7 can validly be received 
before the current logical record is completed, in which case the FMH-7 con- 
tains sense data indicating data truncation. 


PS performs an optional receive check to determine if the partner LU has vio- 
lated the protocols by allowing the partner transaction program to issue a 
request for confirmation on a conversation whose SYNC_LEVEL is NONE. 


Logical record processing begins anew following receipt of an FMH-7. 


Referenced procedures, FSMs, and data structures: 


PS_PROTOCOL_ERROR page 5.0-15 
PROCESS _FMH7_PROC page 5.1-46 
PROCESS_DATA_PROC , page 5.1-44 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
FSM_POST page 5.1-66 
RCB | page A-7 

BUFFER_ELEMENT page A-8 


Call FSM_POST(RECEIVE_IMMEDIATE) (page 5.1-65); 
to reset posting, if activated. 
If RCB.HS_TO_PS_BUFFER_LIST is not empty then 
Set BUFFER_ELEMENT to first entry of the list. 


If partner sent CONFIRM, DEALLOCATE_CONFIRM, DEALLOCATE_FLUSH, 
PREPARE_TO_RCV_CONFIRM, or PREPARE_TO_RCV_FLUSH 
before completing sending of the logical record, or 
partner sent CONFIRM, PREPARE _TO_RCV_CONFIRM, or DEALLOCATE on a 
conversation with SYNC_LEVEL = NONE then (as an implementation-dependent option) 
Call PS_PROTOCOL_ERROR (page 5.0-15) 
with X'10010000' for RU Data Error. 


Else 
Remove BUFFER_ELEMENT from the list. 


Select based on BUFFER_ELEMENT type: 
When CONFIRM 
Set RETURN_CODE parameter to OK. 
Set WHAT_RECEIVED parameter CONFIRM. 
Call FSM_CONVERSATION(R, CONFIRM_INDICATOR, RCB) (page 5.1-63). 
When PREPARE_TO_RCV_CONFIRM 
Set RETURN_CODE parameter to OK. 
Set WHAT_RECEIVED parameter to CONFIRM_SEND. 
Call FSM_CONVERSATION(R, CONFIRM_SEND_INDICATOR, RCB) (page 5.1-63). 
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When PREPARE_TO_RCV_FLUSH 
Set RETURN_CODE parameter to OK. 
Set WHAT_RECEIVED parameter to SEND. 
Call FSM_CONVERSATION(R, SEND_INDICATOR, RCB) (page 5.1-63). 
When DEALLOCATE_CONFIRM 
Set RETURN_CODE parameter to OK. 
Set WHAT_RECEIVED parameter to CONFIRM_DEALLOCATE. 
Call FSM_CONVERSATION(R, CONFIRM_ DEALLOCATE _INDICATOR, RCB) (page 5.1-63). 
When DEALLOCATE_FLUSH 
Set RETURN_CODE parameter to DEALLOCATE_NORMAL. 
Call FSM_CONVERSATION(R, CONFIRM_DEALLOCATE_NORMAL_RC, RCB) (page 5.1-63). 
When FMH7 
Call PROCESS_FMH7_PROC(RCB, BUFFER_ELEMENT.DATA, RECEIVE verb parameters ) 
(page 5.1-46). 
When DATA 
Call PROCESS_DATA_PROC(RCB, BUFFER_ELEMENT.DATA, RECEIVE verb parameters) 
(page 5.1-44). 
If length of BUFFER_ELEMENT.DATA > 0 then 
Insert BUFFER_ELEMENT at the beginning of the RCB.HS_TO_PS_BUFFER_LIST. 


POST_AND_WAIT_PROC 


FUNCTION: Establishes post conditions for a resource and waits for information to arrive 
from HS to cause those post conditions to be satisfied. 


INPUT: The RCB corresponding to the resource to be posted, a FILL indicator speci fy- 


ing whether data is to be received independent of its logical record format 
(FILL = BUFFER versus LL), and the length of the maximum amount of data that 
is to be received 


OUTPUT : The post conditions are satisfied on return to the calling procedure. 


Referenced procedures, FSMs, and data structures: 


TEST_FOR_POST_SATISFIED page 5.1-58 
PROCESS_RM_OR_HS_TO_PS_RECORDS page 5.1-47 
FSM_POST page 5.1-66 
RCB | page A-7 


Call FSM_POST(POST_ON_RECEIPT) (page 5.1-66). 

Set RCB.POST_CONDITIONS.FILL to supplied FILL parameter. 

Set RCB.POST_CONDITIONS.MAX_LENGTH to the supplied LENGTH parameter. 
Call TEST_FOR_POST_SATISFIED(RCB) (page 5.1-58). 


Do while state of FSM_POST # POSTED: 
Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, SUSPEND) (page 5.1-47). 
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FUNCTION: Continues the processing of a PREPARE_TO_RECEIVE when TYPE = SYNC_LEVEL and 
the SYNC_LEVEL of the conversation is CONFIRM. 


INPUT: PREPARE_TO_RECEIVE verb parameters and the RCB corresponding to the resource 
specified in the PREPARE _TO_ RECEIVE 


OUTPUT: See below. 


NOTES:. If a CONVERSATION_FAILURE has been received from the resources manager, PS 
returns to the transaction program after setting the RETURN_CODE parameter of 
the PREPARE_TO_RECEIVE verb to RESOURCE_FAILURE. 


If a RECEIVE_ERROR has been received from HS, PS sends a SEND_DATA_RECORD with 
the TYPE field set to PREPARE_TO_RCV_FLUSH to HS. (Any data in the RCB send 
buffer was purged when the RECEIVE_ERROR record was received.) PS then waits 
for the expected FMH-7 error message to arrive. The RETURN_CODE parameter of 
the PREPARE_TO_RECEIVE verb is set based on the sense data carried in the 
FMH-7. 


If no error or failure condition has occurred, PS sends a SEND_DATA record 
with the TYPE field set to PREPARE_TO_RCV_CONFIRM to HS and waits for a CON- 
FIRMED reply. 


If no session has been allocated to this conversation (i.e., the ALLOCATE that 
allocated the conversation specified RETURN_CONTROL = 
DELAYED_ALLOCATION_PERMITTED), PS now requests a session from the resources 
manager. If, while attempting to allocate a session, the local LU detects an 
error, PS sets the RETURN_CODE field in the PREPARE_TO_RECEIVE to reflect the 
type of allocation error and returns control to the transaction program. 


If the local LU has detected an error while attempting to allocate a session 
to this conversation, but PS has not yet had the opportunity to relay that 
information to the transaction program, it does so at this time by setting the 
RETURN_CODE parameter of the PREPARE_TO_RECEIVE to reflect the type of allo- 
cation error. 


Referenced procedures, FSMs, and data structures: 


PROCESS RM_OR_HS_TO_PS_RECORDS page 5.1-47 
SEND_DATA_TO_HS_ PROC page 5.1-52 
POST_AND_WAIT_PROC page 5.1-40 
DEQUEUE_FMH7_FROC page 5.1-36 
WAIT_FOR_CONFIRMED_PROC page 5.1-59 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE | page 5.1-65 
RCB page A-7 

SEND_DATA_RECORD page A-24 

RECEIVE_ERROR page A-1l2 


Call FSM_CONVERSATION(S, PREPARE_TO_RECEIVE_CONFIRM, RCB) (page 5.1-63). 
Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 


Select based on state of FSM_ERROR_OR_FAILURE (page 5.1-65): 
When CONV_FAILURE_PROTOCOL_ERROR (see Note 1) 
Set RETURN_CODE of PREPARE_TO_RECEIVE to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
When CONV_FAILURE_SON (see Note 1) 
Set RETURN_CODE of PREPARE_TO_ RECEIVE to RESOURCE _FAILURE_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAITLURE_RC» RCB) (page 5.1~-63). 
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When RCVD_ERROR (see Note 2) 
Set PS_TO_HS_RECORD.TYPE to PREPARE_TO_RCV_FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
Call POST_AND_ WAIT_ PROC(RCB, LL, X'7FFF') to receive the ‘issile 
FMH7 (page 5.1- 40). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON then | 
a‘ Set RETURN_CODE of. PREPARE_ TO_RECEIVE to RESOURCE _ FAILURE _RETRY. 
Else 
Set RETURN_CODE of PREPARE_TO_RECEIVE to RESOURCE_FAILURE_NO_RETRY. 
‘ Call FSM_CONVERSATION(R; RESOURCE_ FAILURE_RC, RCB) (page 5.1-63). 
Else 
Call DEQUEUVE_FMH7_ PROC( PREPARE TO_RECEIVE parameters; RCB) (page §.1-36). 
When NO_RQS (see Note 3): 
If LOCKS supplied parameter is SHORT then 
Set RCB.PS_TO_HS.TYPE to PREPARE_TO_RCV_CONFIRM_SHORT. 


Else 
Set RCB.PS_TO_HS.TYPE to PREPARE _TO_RCV_CONFIRM_ LONG. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is 
ALLOCATE_FAILURE_RETRY | ALLOCATE_FAILURE_NO_RETRY | SYNCLEVEL_NOT_SUPPORTED 
(see Note 4) then 
Set RETURN_CODE of PREPARE_TO_RECEIVE to ALLOCATION_ERROR with a subcode 
of ALLOCATION_FAILURE_RETRY, ALLOCATION _FAILURE_NO_RETRY> 
or SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. | 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 


Else 
Call WAIT_FOR_CONFIRMED_PROC( PREPARE_TO_RECEIVE parameters, RCB) (page 5.1-59). 


— When ALLOCATE_FAILURE_RETRY | ALLOCATE_FAILURE_NO_RETRY | SYNCLEVEL_NOT_SUPFORTED 


Set RETURN_CODE of PREPARE_TO_RECEIVE to ALLOCATION_ERROR with a subcode 
of ALLOCATION_FAILURE_RETRY, ALLOCATION_FAILURE_NO_RETRY, 

or SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 

Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 
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PREPARE_TO_RECEIVE_FLUSH_PROC 


FUNCTION: Continues the processing of a PREPARE_TO_RECEIVE when TYPE = FLUSH, or TYPE = 
SYNC_LEVEL and the SYNC_LEVEL of the conversation is NONE. 


INPUT: PREPARE_TO_RECEIVE verb parameters and the RCB corresponding to the resource 
specified in the PREPARE_TO RECEIVE 


OUTPUT: The RETURN_CODE is set to OK. See below for additional output. 


NOTES: 1. If a RECEIVE_ERROR record has been received from HS, or no error records have 
been received, PS sends any data remaining in the RCB send buffer to HS with 
the TYPE indicator set to PREPARE_TO_RCV_FLUSH. (If a RECEIVE ERROR was 
received, any data in PS's send buffer has already been purged. ) 


2. If a locally detected allocation error (i.e.; an allocation error detected by 
the local LU) or a conversation failure mas occurred, no action is taken. PS 
reports the error +s the transaction program at a later time. 


ae. 


Ref=,;enced procedures, FSMs, and data structures: 


PROCESS RM_OR_HS_TO_PS_RECORDS page 5.1-47 
SEND_DATA_TO_HS_PROC page 5.1-52 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A~-7 
RECEIVE ERROR page A-12 
PS_TO_HS_RECORD page A-24 


Call PROCESS_RM_OR_HS_TO_PS_RECORDS(RCB.RCB_ID, NO_SUSPEND) (page 5.1-47). 


If the state of FSM_ERROR_OR_FAILURE (page 5.1-65) is RCVD_ERROR or NO_RQS then 
Set RCB.PS_TO_HS_RECORD.TYPE to PREPARE_TO_RECEIVE_FLUSH. 
Call SEND_DATA_TO_HS_PROC with RCB (page 5.1-52) 

Set RETURN_CODE of PREPARE_TO_RECEIVE to OK. 

Call FSM_CONVERSATION(S, PREPARE_TO_RECEIVE_FLUSH, RCB) (page 5.1-63). 
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PROCESS_DATA_PROC 


FUNCTION: Handles the processing of a DATA buffer element from the HS_TO_PS BUFFER_LIST. 


The procedure first checks to see if the data at the beginning of the buffer 
is a PS header or a_ logical record having an invalid LL value, in order to 
take appropriate action. 


If the data at the beginning of the buffer is not a PS header or an invalid 
LL, further processing of the DATA buffer element occurs, as described below. 


INPUT: The RCB corresponding to the resource specified in the passed RECEIVE verb 
parameters, the DATA buffer element from the HS_TO_PS_BUFFER_LIST, and RECEIVE 
verb parameters. | 


OUTPUT: The RETURN_CODE and WHAT_RECEIVED parameters of the RECEIVE verb are updated. 


NOTES: 1. If the data in the passed BUFFER_DATA begins on a logical record boundary 
(i.e., the last data passed to the transaction program was a complete conver- 
sation record or the last remaining portion of a logical record, or no data 
has been passed to the transaction program since it last entered the receive 
state) and both bytes of the next logical record's LL field are present in 
BUFFER_DATA, data is moved from the BUFFER_DATA parameter to the DATA parame- 
ter of the passed RECEIVE verb. 


2. If the data in the passed BUFFER_DATA begins on a logical record boundary, but 
only the first byte of the next 2-byte LL field is present in BUFFER_DATA, 
this procedure checks to see if any other information has been received fol- 
lowing the first byte of the LL. If the LL has been truncated by receipt of 
an FMH-7, the LL byte is placed in the DATA parameter of the passed RECEIVE 
verb and control is returned to the transaction program. (The FMH-7 is proc- 
essed when the transaction program issues another record.) If the LL has been 
truncated invalidly by receipt of information other than an FMH-7, the partner 
LU has committed a protocol violation and the session over which the conversa- 
tion is occurring is deactivated. If no information follows the first byte of 
the LL, it is saved in the buffer and control is returned to the transaction 
program. (The first byte of the LL is not passed to the transaction program. 
Until the second byte of the 2-byte LL field arrives, PS does not know if the 
LL is associated with a logical record or with a PS header.) 


3. If the data in the passed BUFFER_DATA does not begin on a conversation record 
boundary (i.e.» part, but not all, of a logical record has already been passed 
to the transaction program), data is moved from the BUFFER_DATA to the DATA 
parameter of the passed RECEIVE verb. 


Referenced procedures, FSMs, and data structures: 


PS_SPS page 5.3-35 
PS_PROTOCOL_ERROR page 5.0-15 
RECEIVE_DATA_PROCESSING page 5.1-50 
RCB page A-7 


Select based on the following conditions: 
When BUFFER_DATA is the beginning of a logical 
record and is a PS header 
If RCB.SYNC_LEVEL = SYNCPT then 
Call PS_SPS (page 5.3-35). 
Else (as an implementation-dependent option) 
Call PS_PROTOCOL_ERROR (page 5.0-15) 
with X'10010000' for RU Data Error | 
When BUFFER_DATA is the beginning of a logical record and 
has an invalid LL (as an implementation-dependent option) 
Call PS_PROTOCOL_ERROR (page 5.0-15) 
with X'10010000' for RU Data Error. 
Otherwise 
Select based on the following conditions: 
When BUFFER_DATA is the beginning of a logical 
record and its length is greater than 1 
Call RECEIVE_DATA_PROCESSING (RCB, BUFFER_DATA, RECEIVE verb parameters ) 
(page 5.1-50). 7 
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When BUFFER_DATA is the beginning of a logical record and | 
its length is 1 (i.e., LL field possibly split at buffer boundaries): 
If HS_TO_PS_BUFFER_LIST is not empty then 
If buffer in the HS_TO_PS_BUFFER_LIST is of FMH-7 type then 

Set RETURN_CODE of the RECEIVE verb to OK. 

If RCB.POST_CONDITIONS.MAX_LENGTH > 0 then 
Set DATA of RECEIVE verb to BUFFER_DATA. 
Set BUFFER_DATA to null value. 
Set LENGTH of RECEIVE verb to l. 

If RCB.POST_CONDITIONS.FILL = BUFFER then 
Set WHAT_RECEIVED of receive verb to DATA. 


Else 
Set WHAT_RECEIVED of RECEIVE verb to DATA_INCOMPLETE. 


Else (optional installation check) 
Call PS_PROTOCOL_ERROR (page 5.0-15) 
with X'10010000' for RU Data Error. 
Else (i.e., buffer list is empty) 
Set RETURN_CODE of RECEIVE verb to UNSUCCESSFUL. 
When BUFFER_DATA is the continuation of a logical record partially 
already received: 
Call RECEIVE_DATA_PROCESSING(RCB.BUFFER_DATA, RECEIVE verb parameters ) 
(page 5.1-50). 


Chapter 5.1. Presentation Services--Conversation Verbs 


51-45 


PROCESS_FMH7_PROC _ 


PROCESS_FMH7_PROC 


Invoked upon encountering an FMH-7 buffer element in the HS_TO_PS_BUFFER_LIST. 


The RETURN_CODE parameter of the passed transection program verb is set based 
upon the sense data carried in the FMH-7. If the FMH-7 indicates that log 
data follows, this procedure simulates a RECEIVE_AND WAIT verb and causes 
receive processing to take place. The RECEIVE_AND_WAIT processing waits for a 
logical record, which consists of the log data, to arrive from HS. If the 
sense data carried in the FMH-7 indicates a type of DEALLOCATE_ABEND_® this 
procedure retrieves the deallocation notification from the receive buffer 
before returning to the transaction progras. 


The RCB corresponding to the resource to which the FMH-7 applies, the received 
FMH-7, and the transaction program verb currently being processed 


The RETURN_CODE parameter of the verb is set, based upon the sense data car- 


ried in the passed FMH-7;3 if log data follows the FMH-7, PS retrieves the log- 


ical record containing the Error Log GDS variable and places it (minus the LL 
and GDS ID fields) in the system error log of the local LU. 


This error occurs when the FMH-7 specifies that log data follows, but no log 
data is present. | 


Referenced procedures, FSMs, and data structures: 


PS_PROTOCOL_ERROR ’ | page 5.0-15 
POST_ AND_WATT_PROC | page 5.1-40 
PERFORM_RECEIVE_PROCESSING , page 5.1~-39 
SET_FMH7_RC | page 5.1-57 
FSM_CONVERSATION 7 page 5.1-63 
RCB | page A-7 


As an implementation-dependent option perform receive check of the FMH-7. 
If error found then 
Call PS_PROTOCOL_ERROR (page 5.0-15) 
with X'10086000' (Request Error--FMH Length Incorrect) or with 
X'1L008200E' (Request Error--Invalid Concatenation Bit). 
Set RCB.RECEIVE_LL_REMAINDER to 0. 


If Error Log 


Call POST_ 


60S variable follows then 
AND_WAIT_PROC(RCB, LL, X'7FFF') (page 5.1-40) 


to get the whole GOS variable. 
Create and initialize RECEIVE_AND_WAIT verb parameters. Set the 


RESOURCE 


parameter to RCB.RCB_ID, FILL to LL», and LENGTH to X'7FFF*. 


Call PERFORM_RECEIVE_PROCESSING(RCB, RECEIVE_AND_WAIT parameters) (page 5.1-39). 
If RETURN_CODE of RECEIVE_AND_WAIT is OK and WHAT_RECEIVED 
is DATA_COMPLETE then 


Insert 


error data into system error log. 


Else (as an implementation-dependent option) 
Call PS_PROTOCOL_ERROR (page 5.0-15) 
with X'1008201D' (log data is expected but absent). 
If sense data is DEALLOCATE_ABEND then 
Call PROCESS_RM_OR_HS_TO_PS_RECORDS (page 5.1-47) | 
with RCB_ID and SUSPEND, and remove DEALLOCATE buffer from RCB.HS_TO_PS_BUFFER_LIST. 
If no DEALLOCATE_FLUSH or DEALLOCATE_CONFIRM is found then 
Call PS_PROTOCOL_ERROR (page 5.0-15) with X‘'1008201D'. 
If the state of FSM_CONVERSATION (page 5.1-63) = SEND then 
Set RCB.SEND_LL_REMAINDER to 0. 
Set RCB.SEND_LL_BYTE of RCB to NOT_PRESENT. 
Call SET_FMH7_RC(RCB, FMH-7, transaction program verb parameters) (page 5.1-57). 
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FUNCTION: Processes records received from RM and HS for the conversation identified by 
RCB_ID. If posting has been’ activated for the conversation, the 
TEST_FOR_POST_SATISFIED procedure is called to determine whether the post con- 
ditions have been satisfied by the newly received information. 


RCB_ID, the ID of the conversation and SUSPEND_FLAG. If SUSPEND_FLAG = SUS- 
PEND, this procedure waits for at least one record to be received from RM or 
HS. 


OUTPUT: The RCB associated with each received record is updated to record the receipt 
of the record. 


NOTES: 1. The only records that PS can receive from RM here are CONVERSATION_FAILURE 
records. 


2. RECEIVE_DATA is enqueued in the appropriate RCB.HS_TO_PS_BUFFER_LIST. For 
other HS_TO_PS_RECORDs, an indication that the record was received is stored 
in the appropriate RCB. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
HS page 6.0-3 
RM page 3-18 
RECEIVE_RM_OR_HS_TO_PS_RECORD page 5.1-51 
CONVERSATION_FAILURE_PROC page 5.1-31 
PS_PROTOCOL_ERROR page 5.0-15 
TEST_FOR_POST_SATISFIED page 5.1-58 
FSM_CONVERSATION | page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
FSM_POST page 5.1-66 
RCB page A-7 
RM_TO_PS_RECORD page A-3 
A-1 


HS_TO_PS_RECORD page 


Call RECEIVE_RM_OR_HS_TO_PS_RECORD(RCB_ID, SUSPEND_FLAG) (page 5.1-51) 
to receive RECORD. 
Do while RECORD is not null: 


Select based on the origin of the record: 
When origin is RM 
Call CONVERSATION_FAILURE_PROC (page 5.1-31) 
with RECORD. 
When origin is HS 


Select based on RECORD type: 

When REQUEST_TO_SEND 

Record that a request to send was received 

on this conversation. | 

When RECEIVED_ERROR 

Call FSM_ERROR_OR_FAILURE(RECEIVE_ERROR, RCB) (page 5.1-65). 
When RECEIVE_DATA 

If state of FSM_CONVERSATION is RCV or 

state of FSM_ERROR_OR_FAILURE (page 5.1-65) is RCVD_ERROR then 

Insert the record into RCB.HS_TO_PS_LIST. 


Else (as an implementation-dependent option) 
Call PS_PROTOCOL_ERROR (page 5.0-15) 
with X'20040000' for State Error--Direction. 


Call RECEIVE_RM_OR_HS_TO_PS_RECORD(RCB_ID, SUSPEND_FLAG) (page 5.1-51) 
and receive RECORD. 


If state of FSM_POST (page 5.1-66) is PEND_POSTED then 
Call TEST_FOR_POST_SATISFIED(RCB) (page 5.1-58). 
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5. 1-48 


RCB_ALLOCATED_PROC 


FUNCTION: 


INPUT: 


OUTPUT : 


NOTES: 1. 


Performs further processing of an ALLOCATE request. It is invoked when PS 
receives an RCB_ALLOCATED record from the resources manager. 


The RETURN_CODE parameter of the ALLOCATE verb is set based upon the return 
code field of the RCB_ALLOCATED record. If the return code is OK, PS finishes 
initializing the new RCB (i.e., those fields not already initialized by RM). 
In addition, if the | RETURN_CONTROL parameter of ALLOCATE is 
WHEN_SESSION_ALLOCATED, PS requests that a session be obtained for this con- 
versation. | 


If the return code in RCB_ALLOCATED is not OK, PS sets the RETURN_CODE parame- 
ter of the ALLOCATE appropriately. 


RCB_ALLOCATED record and ALLOCATE verb parameters 
PS creates an FMH-5 Attach header and stores it in the send buffer in the RCB. 


If RETURN_CONTROL = IMMEDIATE, RM has allocated both an RCB and a session as a 
result of receiving ALLOCATE_RCB'- from PS. If RETURN_CONTROL = 
DELAYED_ALLOCATION_PERMITTED, PS defers sending a session request to RM until 
it has accumulated enough data (via SEND_DATAs from the transaction program) 
to fill its send buffer. 


A return code of UNSUCCESSFUL in reply to an ALLOCATE (RETURN_CONTROL = IMME- 
DIATE) indicates that no first-speaker half-sessions are currently available. 


The resources manager returns to PS an ALLOCATE_FAILURE return code to a ses- 
sion allocation request when no sessions having the specified (LU name, mode 
name) pair are active and a condition (either temporary or permanent, = as 
reflected in the return code) exists such that no sessions can currently be 
activated. 


The resources manager returns to PS a SYNC_LEVEL_NOT_SUPPORTED return code to 
a session allocation request when a session having the specified (LU name; 
mode name) pair is active, but the synchronization level specified by the 
transaction program on ALLOCATE is not supported by the partner LU. 


Referenced procedures, FSMs, and data structures: 


OBTAIN_SESSION_PROC | . page 5.1-38 
SEND_DATA_TO_HS_PROC page 5.1-52 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB_ALLOCATED | page A-32 
ATTACH_RECEIVED | | page A-32 
RCB page A-7 
TCB page A-10 
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Select based on RCB_ALLOCATED.RETURN_CODE (see Notes 1, 2,5 and 3): 
When OK 
Set RETURN_CODE of ALLOCATE verb to OK. 
Call FSM_CONVERSATION(S, ALLOCATE, RCB) (page 5.1-63). 
Set RESOURCE parameter of ALLOCATE to RCB identifier. 


Initialize allocated RCB: set RCB.PS_TO_HS_RECORD fields to 

ALLOCATE, FMH, NOT_END_OF_DATA, and null data. 

Set SEND_LL_REMAINDER to 0, RECEIVE_LL_REMAINDER to 0, 

MAX_BUFFER_LENGTH to maximum buffer length allowed 

(implementation dependent), RQ_TO_SEND_RCVD to NO; 

LOCKS to SHORT, POST_CONDITIONS.FILL to LL, 

POST_CONDITIONS.MAX_LENGTH to 0, SEND_LL_BYTE to 

NOT_PRESENT, CONVERSATION_TYPE to TYPE parameter value of ALLOCATE verb, 
and SYNC_LEVEL to ALLOCATE.SYNC_LEVEL. 


Build FMH-5 Attach header (see Appendix H) with data in ALLOCATE. 


If RCB.SECURITY_SELECT parameter is NONE then 
Set the security indicator field of the Attach to user ID is not already verified. 


If RCB.SECURITY_SELECT parameter is SAME then 
If the security user ID is present in the TCB then 
Set the security indicator field of the Attach to user ID is already verified. 
Else 
Set the security indicator field of the Attach to user ID is not already verified. 
Set RCB.SECURITY_SELECT to NONE (represents downgrade 
from previous value of SAME). 


Select based on RCB.SECURITY_SELECT: 
When NONE 
Attach password, profile, and user ID are omitted. 
When SAME 
Attach profile and user ID fields are set using data from the TCB. 
When PGM 
Attach password, profile, and user ID fields are set as specified 
on the ALLOCATE verb. 


Complete building FMH-5 Attach header with remaining data in ALLOCATE (see Appendix H), 
and place itt in the RCB.PS_TO_HS_RECORD.DATA. 


If RETURN_CONTROL parameter is WHEN_SESSION_ALLOCATED 
(see Note 1 for the other cases) then 
Call OBTAIN_SESSION_PROC(RCB, NO_ATTACH) (page 5.1-38). 


If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is 
(ALLOCATE_FAILURE_RETRY | SYNCLEVEL_NOT_SUPPORTED | ALLOCATE_FAILURE_NO_RETRY) then 
Set RETURN_CODE of ALLOCATE to ALLOCATION_ERROR with a subcode of 
ALLOCATION_FAILURE_RETRY, ALLOCATION_FAILURE_NO_ RETRY, or 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 


Else 
If the FMH-5 is to be flushed (as an implementation-dependent option) then 
Set the RCB.PS_TO_HS_RECORD.TYPE to FLUSH. 
Call SEND_DATA_TO_HS PROC (RCB) (page 5.1-52). 
When UNSUCCESSFUL 
Set RETURN_CODE of ALLOCATE to UNSUCCESSFUL. 
When SYNC_LEVEL_NOT_SUPPORTED 
Call FSM_CONVERSATION(S, ALLOCATE, RCB) (page 5.1-63). 
Initialize allocated RCB (for details see above). 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC, RCB) (page 5.1-63). 
Set RETURN_CODE to ALLOCATION_ERROR_SYNC_LEVEL_NOT_SUPPORTED_BY_LU (see Note 4). 
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RECEIVE _DATA_PROCESSING 


FUNCTION: 


INPUT : 


“ Moves data from the passed BUFFER_DATA parameter to the returned DATA parame- 


ter of the passed RECEIVE verb. 


If the transaction program has specified that it is to receive data in terms 
of the logical record format of the data (i.e., RCB.POST_CONDITIONS.FILL = 
LL), data is moved from BUFFER_DATA to the DATA parameter of the passed 
RECEIVE verb. 


If the transaction program has specified that it is to receive data independ- 
ent of the logical record format of the data (i.e., RCB.POST_CONDITIONS. FILL = 
BUFFER), data is moved from BUFFER_DATA to the DATA parameter of the passed 
receive verb one or more times, depending upon the amount of data requested by 
the transaction program and the number of logical records in the buffer. For 
example, if the transaction program has requested 20 bytes of data and 25 
bytes of data (comprising 3 logical records of lengths 7 bytes, 9 bytes, and 9 
bytes, respectively) are in BUFFER_DATA, RECEIVE _DATA_BUFFER_MANAGEMENT is 
invoked once to receive the first logical record (yielding 7 bytes of data in 
the DATA field). It is invoked a second time to receive the second logical 
record (yielding 16 bytes of data in the DATA field). And finally it is 
invoked again to receive the first four bytes of the third logical record 
(yielding 20 bytes of data in the DATA field, which is the awowunt the trans- 
action program requested). 


The entry in the RCB_LIST corresponding to the resource specified in 
RECEIVE_VERB, a data buffer element (DATA_BUFFER) from the 
RCB.HS_TO_PS_BUFFER_LIST, and RECEIVE verb parameters 


The DATA_BUFFER, and WHAT_RECEIVED and DATA parameters of the passed RECEIVE 
verb are updated. 


When FILL = LL is specified, the WHAT_RECEIVED parameter of the RECEIVE verb 
is set to DATA_COMPLETE when a complete logical record or the lest remaining 
portion of a logical record, is passed to the transaction program. Otherwise, 
the WHAT_RECEIVED is set to DATA_INCOMPLETE when FILL = LL is specified. 


Referenced procedures, FSMs,», and data structures: 


RCB 


page A-7 


Select based on RCB.POST_CONDITIONS.FILL: 


When LL 


If already received a complete logical record 


(i.e. 


» RCB.POST_CONDITIONS .MAX_LENGTH = 0) then 


Set WHAT_RECEIVED of receive verb to DATA_INCOMPLETE. 


Else 
Set 


DATA of receive verb to the first LEN bytes 


(LEN ts the smaller of RECEIVE LL REMAINDER and 
RCB.POST_CONDITIONS .MAX_LENGTH) of the DATA_BUFFER and 
subtract LEN from RECEIVE _LL_REMAINDER and 
RCB.POST_CONDITIONS.MAX_LENGTH. Remove the first LEN bytes 
from the DATA_BUFFER. | 


If 


Els 


RECEIVE _LL_REMAINDER = 0 then 

Set WHAT_ RECEIVED of RECEIVE verb to DATA_COMPLETE. 

@ 

Set WHAT_RECEIVED of RECEIVE verb to DATA_INCOMPLETE. 


When BUFFER 
Set WHAT_RECEIVED of RECEIVE verb to DATA. 


Do whi 


le RCB.POST_CONDITIONS.MAX_LENGTH > 0 and 


while the of length BUFFER_DATA > 0 


If 


RECEIVE_LL_REMAINDER = 0 and length of BUFFER_DATA = 1 then 
Set RCB.POST_CONDITIONS.MAX_LENGTH to 0. 


Else 


Set DATA of RECEIVE verb to DATA_BUFFER as described above. 


Set RETURN_CODE of RECEIVE verb to OK. 
Set LENGTH parameter of RECEIVE verb to length of DATA of RECEIVE verb. 
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RECEIVE_RM_OR_HS_TO_PS_RECORD 
RECEIVE_RM_OR_HS_TO_PS_RECORD 


FUNCTION: Returns a record sent by RM (or HS) to the conversation identified by RCB_ID. 


INPUT: RCB_ID (the ID of the conversation), and SUSPEND_FLAG 


OUTPUT: A record received from RM or HS. This record may be null if no record is 
available and SUSPEND_FLAG = NO_SUSPEND. 


NOTE: CONVERSATION_FAILURE is the only possible record that can arrive from RM. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
HS page 6.0-3 
RM page 3-18 
CONVERSATION_FAILURE page A-32 
HS_TO_PS_RECORD page A-12 
RCB page A-7 


If SUSPEND_FLAG = SUSPEND then 
Wait until a record has arr‘ved from RM or HS for 
conversation RCB_ID. 
Else (1.e., wnen SUSPEND_FLAG=NO_SUSPEND ) 
vet the record arrived from RM or HS 
(Record may be null if no record bas arrived yet.) 
Return record. 


SEND_DATA_BUFFER_MANAGEMENT 


FUNCTION: Determines if there is enough data to be sent to HS. 


PS continues to send data to HS until the amount of data remaining to be sent 
is less than or equal to the maximum buffer size, in which case PS stores the 
data in the RCB until more data is issued by the transaction program or the 
buffer is flushed. If the data in the buffer is exactly equal to the maximum 


buffer size, PS stores the data to be sent later. 


INPUT: Data to be sent to HS and the RCB corresponding to the resource specified in 
the current TRANSACTION_PGM_VERB 


OUTPUT: If enough data has been accumulated in the RCB buffer, one or more 
SEND_DATARECORDs are sent to HS. Otherwise, the data is stored in the RCB to 
be sent at a later time. 


Referenced procedures, FSMs, and data structures: 


SEND_DATA_TO_HS_ PROC page 5.1-52 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 


Set TEMP_BUFFER to RCB.PS_TO_HS_RECORD_DATA concatenated to DATA. 
Set NO_ERROR_OR_FAILURE to true. 
Do while length of TEMP_BUFFER > RCB.MAX_BUFFER_LENGTH 
and NO_ERROR_OR_FAILURE 1s true: 
Set RCB.PS_TO_HS_RECORD.DATA to first RCB.MAX_BUFFER_LENGTH bytes 
of the TEMP_BUFFER, remove these bytes from TEMP_BUFFER. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) 
is ALLOCATE_FAILURE_RETRY | ALLOCATE_FAILURE_NO_RETRY | SYNCLEVEL_NOT_SUPPORTED then 
Set NO_ERROR_OR_FAILURE to false. 
Move TEMP_BUFFER into RCB.PS_TO_HS_RECORD.DATA. 
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SEND_DATA_TO_HS_PROC 


Handles the lie J of data to HS to be sent to the partner transaction pro- 
gram. 


If no session has as yet been allocated to the conversation associated with 
the passed RCB, PS nos requests a session from the resources manager. If the 
transaction program has stopped sending data and has issued DEALLOCATE, PRE- 


PARE_TO_RECEIVE, and/or CONFIRM, PS requests RM to send the data, which con- 
tains an Attach header, when RM allocates the session. Otherwise, PS sends 
the data itself when RM has allocated a session. 

The RCB associated with the conversation 


SEND_DATA_RECORD to HS 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
HS inte, te hg one Ay 8 page 6.0-3 
OBTAIN _SESSION_ PROC : sof £2 & & om , page 5.1-36 
RCB , | page A-7 
SEND_DATA_RECORD . 3 page A-24 


If no session has been allocated to this conversation then 
If RCB.PS_TO_HS_RECORD.TYPE. = FLUSH | NOT_END_OF_DATA then 
Call OBTAIN_SESSION_PROC(RCB, NO_ATTACH) (page 5.1-38). 
Create a SEND_DATA_RECORD, cory RCB.PS_TO_HS.RECORD into ute and 
send it to HS. 
Else 
Call OBTAIN_SESSION_PROC(RCB, ATTACH) (page 5. ce 38). 
Else (session previously allocated) 
Create a SEND_DATA_RECORD, copy RCB.PS_TO_HS_RECORD into it, and 
send it to HS. 
Set RCB.PS_TO_HS_RECORD fields as follows: 
ALLOCATE to NO» FMH to NO, TYPE to NOT_ENO_OF_DATA, and DATA to null. 
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SEND_ERROR_DONE_ PROC 
SEND_ERROR_DONE_PROC 


This procedure performs further processing of the SEND_ERROR verb. 


It creates an FMH-7 record, and selects the sense data to be inserted in the 
FMH-7 based upon the type of SEND_ERROR, the state of the conversation, and 
whether the outgoing logical record is complete. If the transaction program 
is in send state and has completed the current logical record, sense data 
indicating that no truncation of data has taken place is inserted into the 
FMH-7. If the transaction program is in. send state and has not completed the 
current logical record, sense data indicating data truncation has occurred in 
inserted into the FMH-7. Finally, if the transaction program is in receive 
state, sense data indicating that data sent by the partner transaction program 
is being purged by the half-session is inserted into the FMH-7. 


Sense data X'08890000' and X'08890100' have either of two meanings, depending 
upon whether the transaction prograw is in send or receive state. 


SEND_ERROR verb parameters and the RCB corresponding to the resource specified 
in the SEND_ERROR 


An FMH-7 is created and stored in the RCB send buffer. If any log data is 
associated with the SEND_ERROR, PS creates an Error Log GOS variable (see "'Ap- 
pendix H. FM Header and LU Services Commands") and stores the GDS variable in 
the RCB send buffer following the FMH-7. PS also places the GDS variable (mi- 
nus the LL and GDS ID fields) in the systew error log at the local LU. PS 
returns to the transaction program with the RETURN_COOE parameter in the 
SEND_ERROR set to OK. 


Referenced procedures, FSMs, and data structures: 


SEND_DATA_TO_HS_ PROC page 5.1-52 
SEND_DATA_BUFFER_MANAGEMENT . page 5.1-51 
FSM_CONVERSATION page 5.1-63 
RCB page A-7 


Select based on the following conditions: 
When TYPE parameter of SEND_ERROR verb is PROG and state 
of FSM_CONVERSATION (page 5.1-63) is SEND 
If data sent by the TP is at a logical record boundary then 
Set SENSE_DATA to X‘'08890000'. 
Else 
Set SENSE_DATA to X'O08890001'. 
When TYPE parameter of SEND_ERROR verb is PROG 
and state of FSM_CONVERSATION (page 5.1-63) is RCV, 
RCVD_CONFIRM, RCVD_CONFIRM_SEND, RCVD_CONFIRM_DEALL 
Set SENSE_DATA to X'08890000'. 
When type of SEND_ERROR is SVC 
and state of FSM_CONVERSATION (page 5.1-63) is SEND 
If data sent by the TP is at a logical record boundary then 
Set SENSE_DATA to X'08890100'. 
Else 
Set SENSE_DATA to xX'08890101". 
When TYPE parameter of SEND_ERROR is SVC 
and state of FSM_CONVERSATION (page 5.1-63) is 
RCV | RCVD_CONFIRM | RCVD_CONFIRM_SEND | RCVD_CONFIRM_DEALL 
Set SENSE DATA to X‘'08890100'. 
If LOG_DATA parameter of SEND_ERROR is not null then 
Move SENSE_DATA into RCB.PS_TO_HS_RECORD.DATA as an FMH-7 record. 
Create Error log GDS variable with the LOG_DATA and concatenate 
it to RCB.PS_TO_HS_RECORD.DATA. 
Insert Error Log 6DS variable into a system error log. 
Else 
Move SENSE_DATA into RCB.PS_TO_HS_RECORD.DATA as an FMH-7 record, 
If FLUSH verb is not implemented or the FMH-7 is 
to be flushed immediately then (as an implementation-dependent option) 
Set type of RCB.PS_TO_HS_RECORD to FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 
Else 
Call SEND_DATA_BUFFER_MANAGEMENT (null data, RCB) (page 5.1-51). 
Set RETURN_CODE of SEND_ERROR to OK. 
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& ° 1-54 


SEND_ERROR_IN_RECEIVE STATE 


FUNCTION: 


INPUT: 


OUTPUT: 


NOTES: 1. 


Referenced procedures, FSMs and data structures: 


Invoked when the transaction program issues a SEND_ERROR for a conversation 
that is in the RECEIVE state. Further processing of the SEND_ERROR is depend- 
ent upon what information, if any,» has been received from HS and stored in the 


HS_TO_PS_BUFFER_LIST, as described below. 


SEND_ERROR verb parameters and the RCB corpesponding to the resource specified 
in the SEND_ERROR record 


See below. 


If a RECEIVE DATA record with TYPE parameter set to DEALLOCATE has been 
received from HS, PS returns to the transaction program after setting the 
RETURN_CODE parameter of the SEND_ERROR to DEALLOCATE_NORMAL. 


If the first element in the RCB.HS_TO_PS_BUFFER_LIST is not a DEALLOCATE buff- 
er element, or if the RCB.HS_TO_PS_BUFFER_LIST is empty» PS sends a SEND_ERROR 
record to HS. PS then creates an FMH-7 and stores it in the RCB send buffer. 


PS page 5.0-5 
HS 7 . page 6.0-3 
WAIT_FOR_SEND_ERROR_DONE_PROC page 5.1-62 
FSM_CONVERSATION | page 5.1-63 
RCB a Oo — page A-7 
SEND_ERROR page A-24 


If first entry on RCB.HS_TO_PS_BUFFER_LIST is DEALLOCATE_ FLUSH (see Note 1) then 
Set RETURN_CODE parameter of the SEND_ ERROR verb to DEALLOCATE_ NORMAL. 
Call FSM_CONVERSATION(R, DEALLOCATE _NORMAL _RC, RCB) (page 5.1- 63). 

Else (see Note 2) 


Send SEND_ 


ERROR record to HS. 


Call WAIT_ FOR_SEND_ERROR_DONE_PROC( SEND_ ERROR verb Mpaemerner ae RCB) page 5.1-62). 
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SEND_ERROR_IN_SEND_STATE 


FUNCTION: Invoked when the transaction program issues a SEND_ERROR verb for a conversa- 
tion that is in the SEND state. 


If the state of FSM_ERROR_OR_FAILURE indicates that no RECEIVE_ERROR record 
has been received from HS, any data in PS's send buffer is sent to HS and an 
FMH-7 is created and stored in the buffer. 


If the state of FSM_ERROR_OR_FAILURE indicates that a RECEIVE_ERROR record has 
been received from HS, PS sends a SEND_DATA record with the TYPE field set to 
PREPARE_TO_RCV_FLUSH to HS. (Any data in the RCB send buffer was purged when 
the RECEIVE_ERROR record was received.) PS then waits for the expected FMH-7 
to arrive. The RETURN_CODE parameter of the SEND_ERROR is set based upon the 
sense data carried in the FMH-7. 


INPUT: SEND_ERROR verb parameters and the RCB corresponding to the resource specified 
in the SEND_ERROR. 


OUTPUT: Any data in PS's buffer is sent to HS and an FMH-7 is created and stored in 
the RCB. 


NOTE : If no session has been allocated to this conversation (i.e., the ALLOCATE verb 
issued to allocate the conversation = specified RETURN_CONTROL = 
DELAYED_ALLOCATION_PERMITTED), PS now requests a session from the resources 
manager. If, while attempting to allocate a session, the local LU detects an 
error, PS sets the RETURN_CODE parameter in the SEND_ERROR to reflect the type 
of allocation error and returns control to the transaction program. 


Referenced procedures, FSMs, and data structures: 


SEND_DATA_TO_HS_PROC page 5.1-52 
SEND_ERROR_DONE_ PROC page 5.1-53 
POST_AND_WAIT_PROC page 5.1-40 
DEQUEUE_FMH7_PROC page 5.1-36 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE | page 5.1-65 
RCB page A-7 


If state of FSM_ERROR_OR_FAILURE = NO_RQS then 
Set CONTINUE to true. 


If RCB.PS_TO_HS_RECORD.TYPE is not null then 
Set RCB.PS_TO_HS_RECORD.TYPE to FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 


If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is 
ALLOCATE_FAILURE_RETRY | ALLOCATE_FAILURE_NO_RETRY 
| SYNCLEVEL_NOT_SUPPORTED then (see Note) 

Set RETURN_CODE parameter of SEND_ERROR verb to ALLOCATION_ERROR with a subcode of 
ALLOCATION_FAILURE_RETRY, ALLOCATION_FAILURE_NO_RETRY,>» or 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU, as appropriate. 

Call FSM_CONVERSATION(R, ALLOCATION_ERROR_RC» RCB) (page 5.1-63). 

Set CONTINUE to false. 


If CONTINUE then 
Call FSM_CONVERSATION(S, SEND_ERROR, RCB) (page 5.1-52). 
Call SEND_ERROR_DONE_PROC(SEND_ERROR verb parameters, RCB) (page 5.1-53). 
Set RCB.SEND_LL_REMAINDER to 0 and set RCB.SEND_LL_BYTE to NOT_PRESENT to 
indicate that the data sent by TP is at a logical boundary. 
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SEND_ERROR_IN_SEND_STATE 


Else (1.e.,5 RCVD_ ERROR) 
Set RCB.PS_ TO_ HS_RECORD type to PREPARE_TO_RCV_FLUSH. 


Call SEND_ 
Call POST_ 
when the 


DATA. TO_ HS_PROC(RCB) (page 5. 1-52). 
AND _WALT_ PROC(RCB, LL» X'7FFF*) (page 5.1-40) to post 
whole FMH7 is received. 


If state of FSM_ERROR_OR_FAILURE (page 5. 1-65) is CONV_FAILURE_SON or 
CONV_FAILURE_PROTOCOL_ ERROR then 


If, stat 
— - Set 
Else 


e of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON then 
RETURN_CODE to RESOURCE_FAILURE_RETRY. 


Set RETURN_CODE to RESOURCE_ FAILURE_ NO_RETRY. 
Call FSM SCUNVER SRT ONT: RESOURCE_ FAILURE_RC, RCB) iesee 5.1-63)}. 


Else 
Call DE 


QUEVE_FMH7_ PROC( SEND_ ERROR verb parameters, RCB) (page 5.1-36). 


SEND_ERROR_TO_HS_PROC 


FUNCTION: 
INPUT: 


OUTPUT: 


Referenced procedures, FSMs, and data structures: 


This procedure creates a SEND_ERROR and sends it to HS. 


The RCB associated with the HS to which the SEND_ERROR is to be sent 


SEND_ERROR (a variant of PS_TO_HS_RECORD) to PS 


PS page 5.0-5 
RCB : page A-7 
SEND_ERROR | page A-24¢ 


Create a SEND_ERROR record (page A-24) with RCB.RCB_ID. 


Send this SEND_ERROR record to HS. 
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SET_FMH7_RC 
SET_FMH7_RC 


FUNCTION: Sets the RETURN_CODE parameter of the passed transaction program verb based 
upon the sense data carried in the passed FMH-7. 


INPUT: The RCB corresponding to the resource to which the FMH-7 applies, the received 
FMH-7, and the transaction program verb parameters currently being processed 


OUTPUT: The RETURN_CODE parameter of the verb is set, based upon the sense data car- 
ried in the FMH-7. 


Referenced procedures, FSMs, and data structures: 


PROCESS_RM_OR_HS_TO_PS_RECORDS page 5.1-47 
PS_PROTOCOL_ERROR page 5.0-15 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 


Select based on the Sense Data in FMH-7: 
When ALLOCATION_ERROR code 
Call PROCESS_RM_OR_HS_TO_PS_RECORDS with RCB_ID and SUSPEND (page 5.1-47), 
and remove DEALLOCATE buffer from RCB.HS_TO_PS_BUFFER_LIST. 
If neither DEALLOCATE_FLUSH nor DEALLOCATE_CONFIRM are found then 
Call PS_PROTOCOL_ERROR (page 5.0-15) with X'1008201D'. 
Set RETURN_CODE parameter of the verb to the corresponding value (see Appendix H to 
find the value corresponding to a given Sense Data). 
Call FSM_CONVERSATION(R, ALLOCATION_ERROR, RCB) (page 5.1-63). 
When RESOURCE_FAILURE_NO_RETRY 
Set RETURN_CODE parameter of the TP verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
When PROG_ERROR_NO_TRUNC or PROG_ERROR_PURGING 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is RCVD_ERROR then 
Set RETURN_CODE parameter of the verb to PROG_ERROR_PURGING. 


Else 
Set RETURN_CODE parameter of the verb to PROG_ERROR_NO_TRUNC. 
Call FSM_CONVERSATION(R, PROGRAM_ERROR_RC, RCB) (page 5.1-63). 
When PROG_ERROR_TRUNC 
Set RETURN_CODE parameter of the verb to PROG_ERROR_TRUNC. 
Call FSM_CONVERSATION(R, PROGRAM_ERROR_RC, RCB) (page 5.1-63). 
When SVC_ERROR_NO_TRUNC or SVC_ERROR_PURGING 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is RCVD_ERROR then 
Set RETURN_CODE parameter of the verb to SVC_ERROR_PURGING. 


Else 
Set RETURN_CODE parameter of the verb to SVC_ERROR_NO_TRUNC. 
Call FSM_CONVERSATION(R, SERVICE _ERROR_RC) (page 5.1-63). 
When SVC_ERROR_TRUNC 
Set RETURN_CODE parameter of the verb to SVC_ERROR_TRUNC. 
Call FSM_CONVERSATION(R, SERVICE_ERROR_RC, RCB) (page 5.1-63). 
When DEALLOCATE_ABEND 
Set RETURN CODE parameter of the verb to DEALLOCATE_ABEND_PROG, DEALLOCATE_ABEND_SVC, 
DEALLOCATE_ABEND_TIMER, or to DEALLOCATE_ABEND_RC 
as shown in Appendix G under X'0864' Sense Code. 
Call FSM_CONVERSATION(R, DEALLOCATE_ABEND_RC, RCB). 
Otherwise (as an implementation-dependent option): 
Call PS_PROTOCOL_ERROR (page 5.0-15) with FMH-7 Sense Data. 
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TEST_FOR_POST_SATISFIED 


TEST_FOR_POST_SATISFIED 


Tests whether the post conditions specified in the RCB have been satisfied. 
The entry in the RCB_LIST corresponding to the resource to be tested. 
The state of FSM_POST is set to POSTED if the post conditions are satisfied. 


If there are no entries on the HS_TO_PS_BUFFER_LIST, the resource cannot be 
posted. 


Receipt of a CONFIRM, PREPARE_TO_RCV, or DEALLOCATE indicator causes the con~- 
versation to be posted. A later (optional) receive check determines if the 
received indicator invalidly truncates a logical record and, if so» appropri- 


ate action is taken at that time. Similarly, receipt of a logical record with 
associated LL field containing an invalid value or indicating a PS header 
causes posting to occur. Processing of the invalid LL or PS header takes 
place at a later time. 


The high-order bit of the LL field is a Continuation bit, which is on unless 
this logical record is the final one in the current 6DS5 variable. (Continued 
GDS variables and the information in this bit are specific to "Chapter 5.2. 
Presentation Services--Mapped Conversation Verbs" in Chapter 5.2). 


If more than one entry is on the RCB.HS_TO_PS_BUFFER_LIST, one of the entries 
wust be a CONFIRM, PREPARE_TO_RCV, or DEALLOCATE indicator, which causes the 
conversation to be posted. 


Referenced procedures, FSMs, and data structures: 


FSM_POST page 5.1-66 
RCB page A-7 
BUFFER_ELEMENT page A-8 
Select based on number of entries in the RCB.HS_TO_PS_BUFFER_LIST: 
When 0 
Do nothing (see Note 1). 
When 1 


Select based on the type of the first buffer in the list: 
When CONFIRM | PREPARE_TO_RCV_CONFIRM | PREPARE_TO_RCV_FLUSH | 
DEALLOCATE_CONFIRM | DEALLOCATE_FLUSH | FMH7 
Call FSM_POST (page 5.1-66) and pass it a POST signal (see Note 2). 
When DATA 
Select based on RCB.POST_CONDITIONS.FILL: 
When BUFFER 
If length of buffer data 2 maximum length in POST_CONDITIONS, 
or if PS header or invalid length present (see Appendix H) then 
Call FSM_POST (page 5.1-66) and pass it a POST signal. 
When LL 
If RCB.RECEIVE_LL_REMAINDER = 0 and length of buffer data 2 2 then 
If PS header or invalid LL (see Appendix H and Note 3) then 
Call FSM_POST (page 5.1-66) and pass it a POST signal. 


Else 
Calculate RCB.RECEIVE_LL_REMAINDER from LL in the buffer 
and high order bit forced to 0. 
If length of buffer 2 RCB.RECEIVE _LL_REMAINDER 
or 2 RCB.POST_CONDITIONS.MAX_LENGTH then 
Call FSM_POST (page 5.1-66) and pass it a POST signal. 
Else 
Do nothing. 
Else 
If length of buffer data 2 RCB_RECEIVE_LL_REMAINDER 
or 2 RCB.POST_CONDITIONS.MAX_LENGTH then 
Call FSM_POST (page 5.1-66) and pass it a POST signal. 
Otherwise (number of entries is 2 2, see Note 4) 
Call FSM_POST (page 5.1-66) and pass it a POST signal. 
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FUNCTION: 


INPUT: 


OUTPUT : 


NOTES: 


WAIT_FOR_CONFIRMED_PROC 
WAIT_FOR_CONFIRMED_PROC 


Invoked after a SEND_DATA record indicating CONFIRM has been sent to HS and a 
CONFIRMED record is expected in reply. 


HS can send other records to PS while PS is waiting for the expected CONFIRMED 
record. Appropriate action is taken, depending upon the record received (see 
below). 


The transaction program verb that caused the CONFIRM indicator to be sent to 
HS, and the RCB corresponding to the resource specified in the transaction 
program verb 


See below. 


If a REQUEST_TO_SEND record is received, PS stores that information in the RCB 
to be relayed to the transaction program at a later time, and continues to 
wait for the expected CONFIRMED record. 


If a RECEIVE_ERROR record is received, PS waits for the FMH-7 record corre- 
sponding to the RECEIVE_ERROR to arrive from HS. The RETURN_CODE of the 
passed transaction program verb is set based upon the sense data carried in 
the FMH-7. Control is then returned to the transaction program. 


If the expected CONFIRMED is received, PS returns control to the transaction 
program. 


If the transaction program has issued a DEALLOCATE (TYPE = SYNC_LEVEL) and the 
SYNC_LEVEL of the conversation is CONFIRM, FSM_CONVERSATION will be in the 
The CONFIRMED record 


PEND_DEALL state when tine CONFIRMED record arrives. 
causes the requested deallocation to be completed. 


Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
HS page 6.0-3 
RM page 3-18 
RECEIVE_RM_OR_HS_TO_PS_RECORD page 5.1-51 
CONVERSATION_FAILURE_PROC page 5.1-31 
POST_AND_WAIT_PROC page 5.1-40 
DEQUEUE_FMH7_ PROC page 5.1-36 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 
HS_TO_PS_RECORD page A-12 
RM_TO_PS_RECORD page A-32 


Set CONTINUE to true. 
Do while CONTINUE is true: 
Wait for record to arrive. 
If record arrived from RM then 
Call CONVERSATION_FAILURE_PROC with record (see page 5.1-31). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON then 
Set RETURN_CODE parameter of the verb to RESOURCE _FAILURE_RETRY. 
Else 
Set RETURN_CODE parameter of the verb to RESOURCE_FAILURE_NO_RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
Set CONTINUE to false. 
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WAIT_FOR_CONFIRMED_PROC 


5.1-60 


Else (j.e., record arrived from HS) 
Select based on record type: 
When REQUEST_TO_SEND 
Record in the RCB that request to send was received on the conversation. 
When RECEIVE ERROR . 
Call FSM_ERROR_OR_FAILURE(RECEIVE_ERROR, RCB) (page 5.1-65). 
Call POST_AND_WAIT_PROC(RCB, LL, X'7FFF') (page 5.1-40). 
If state of FSM_ERROR_OR_FAILURE (page 5.1-65) is CONV_FAILURE_SON or 
_.CONV_FAILURE_ PROTOCOL. ERROR then 
If state of FSM_ERROR_OR_FAILURE (page 5. 1-65) is CONV. FAILURE_SON then 
Set RETURN_CODE parameter of the verb to RESOURCE_FAILURE_ RETRY. 
Else 
Set RETURN_CODE parameter of the verb to RESOURCE_FAILURE_NO_ RETRY. 
Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
Else 
Call DEQUEUE_FMH7_PROC(CONFIRM verb parameters, RCB) (page 5.1-36). 
Set CONTINUE to false. 
When CONFIRMED 
Set RETURN_CODE parameter of the verb to OK. 
If state of FSM_CONVERSATION is PEND_DEALL then , 
Call FSM_CONVERSATION(R, DEALLOCATION. INDICATOR, RCB) (page 5.1- -63). 
Purge all records from HS to PS process. 
Create DEALLOCATE_RCB, initialize it, and send it to RM. 
Set CONTINUE to FALSE. 


WAIT_FOR_RM_REPLY 


FUNCTION: Waits for an expected reply from the LU resources manager. 
INPUT: None 
OUTPUT: A record received from the resources manager 


NOTES: 1. CONVERSATION_FAILURE is the only record that can arrive unexpectedly from the 
resources manager. 


2. Anv record from the resources manager, other than CONVERSATION_FAILURE must be 
the expected reply. No more than one reply from the resources manager is out- 
standing at any time. 
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Referenced procedures, FSMs, and data structures: 


PS page 5.0-5 
RM page 3-18 
CONVERSATION_FAILURE_PROC page 5.1-31 
RM_TO_PS_RECORD page A-32 


Set CONTINUE to true. 
Do while CONTINUE is true: 
Wait until RM_TO_PS_RECORD has arrived from RM. 
If RM_TO_PS_RECORD type is CONVERSATION_FAILURE then 
Call CONVERSATION _FAILURE_PROC(RM_TO_PS_RECORD) (page 5.1-31). 


Else 


Set CONTINUE to false. 
Return with RM_TO_PS_RECORD. 
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WAIT_FOR_RSP_TO_RQ_TO_SEND_ PROC 
WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 


FUNCTION: Invoked after PS has issued a REQUEST_TO_SEND to HS. The next record that is 
expected from HS is RSP_TO_REQUEST_TO_SEND. 


HS can send records to PS while PS is waiting for the expected 
RSP_TO_REQUEST_TO_SEND record. Appropriate action is taken, depending upon 
the record received (see below). 


The RCB corresponding to the conversation for which the REQUEST_TO_SEND was 
issued i158 passed as a parameter to this procedure; HS_TO_PS_RECORDs are 
received from HS. 


OUTPUT: See below. 


NOTES: 1. If a REQUEST_TO_SEND is received, PS stores that information in the RCB and 
continues to wait for the RSP_TO_REQUEST_TO_SEND. 


Since REQUEST_TO_SEND has no RETURN CODE parameter, if a RECEIVE_ERROR is 
received, the information is stored in FSM_ERROR_OR_FAILURE to be presented to 
the transaction program when it issues a record that does have a RETURN_CODE 
field. 


When RSP_TO_REQUEST_TO_SEND is received, control is returned to the trans- 
action program. 


Any data received from HS before the RSP_TO_REQUEST_TO_SEND arrives is stored 
in the HS TO_PS BUFFER_LIST. PS continues to wait for the 
RSP_TO_REQUEST_TO_SEND. However, if a RECEIVE_DATA record with TYPE field set 
to DEALLOCATE_FLUSH is received, the RSP_TO_REQUEST_TO_SEND will not be 
received by PS, so PS returns control to the transaction program. 


Referenced procedures, FSMs, and data structures: 


RECEIVE _RM_OR_HS_TO_PS_RECORD page 5.1-51 
CONVERSATION_FAILURE_PROC page 5.1-31 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 
BUFFER_ELEMENT page A-8 


Set CONTINUE to true. 
Do while CONTINUE 1s true: 
Call RECEIVE _RM_OR_HS_TO_PS_RECORD(RCB.RCB_ID, SUSPEND }) 
and receive record (page 5.1-51). 
If record arrived from RM then 
Call CONVERSATION_FAILURE_PROC with record (page 5.1-31). 
Set CONTINUE to false. 
If record arrived from HS then 


Select based on the type of the record: 
When REQUEST_TO_SEND (see Note 1) 
Set RCB.RQ_TO_SEND P7VJ to YES. 
When RECEIVE_EPRC.« (see Note 2) 
Cait FSM_ERROR_OR_FAILURE(RECEIVE_ERROR, RCB) (see page 5.1-65) 
When RSP_TO_REQUEST_TO_SEND (see Note 3) 
Set CONTINUE to false. 
When RECEIVE DATA (see Note 4) 
Enqueue record to RCB.HS_TO_PS BUFFER_LIST. 
Set BUFFER_ELEMENT to the last entry of HS_TO_PS_RECORD_LIST. 
If BUFFER_ELEMENT type = DEALLOCATE_FLUSH then 
Set CONTINUE to false. 
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WATT_FOR_SEND_ERROR_DONE_ PROC 


WAIT_FOR_SEND_ERROR_DONE_PROC 


Invoked after a SEND_ERROR record has been sent to HS. The SEND_ERROR was 
sent to HS as a result of the transaction program issuing a SEND_ERROR or 
DEALLOCATE (TYPE = ABEND_PROG, ABEND_SVC, or ABEND_TIMER) for a conversation 
that is in receive state. 


The procedure calls GET_END_CHAIN_FROM_HS (page 5.1-37) to await the arrival 
from HS of a record indicating EC. Appropriate action is taken depending on 
the type of record received. | 


Transaction program verb parameters and the RCB corresponding to the resource 
specified in the verb 


See below. 
If the record received from HS is a RECEIVE_DATA with TYPE field set to DEAL- 


LOCATE_FLUSH, the conversation is deallocated and the return code of the verb 
is set to indicate the deallocation. 


If the record received from HS is a RECEIVE_DATA with TYPE field set to DEAL- 
LOCATE_CONFIRM, CONFIRM, PREPARE_TO_RCV_CONFIRM, or PREPARE_TO_RCV_FLUSH, the 
processing of the verb is continued. 


FSM_ERROR_OR_FAILURE is reset to NO_RQ@S because, in certain SEND_ERROR race 
cases, a RCVD_ERROR condition is not reported to the transaction program. 
Normally, FSM_ERROR_OR_FAILURE is reset to NO_RQS by SET_FMH7_RC (page 5.1-57) 
when the error is reported to the TP. | 


Referenced procedures, FSMs, and data structures: 


GET_END_CHAIN_FROM_HS page 5.1-37 
SEND_ERROR_DONE_ PROC page 5.1-53 
COMPLETE_DEALLOCATE_ABEND_ PROC page 5.1-30 
FSM_CONVERSATION page 5.1-63 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 

BUFFER_ELEMENT page A-8 


Call GET_END_CHAIN_FROM_HS(RCB) (page 5.1-37). 


Select based on the state of FSM_ERROR_OR_FAILURE (page 5.1-65): 

When CONV_FAILURE_SON 

Set RETURN_CODE of the verb to RESOURCE _FAILURE_RETRY. 

Call FSM_CONVERSATION(R, RESOURCE FAILURE RC, RCB) (page 5.1-63). 
When CONV_FAILURE_PROTOCOL_ERROR 

Set RETURN_CODE of the verb to RESOURCE _FAILURE_NO_RETRY. 

Call FSM_CONVERSATION(R, RESOURCE_FAILURE_RC, RCB) (page 5.1-63). 
Otherwise 

Get BUFFER_ELEMENT from HS_TO_PS_BUFFER_LIST. 


Select based on the following conditions: 
When BUFFER_ELEMENT type is DEALLOCATE_FLUSH (see Note 1) and the verb 1s SENO_ERROR 
Set RETURN_CODE of verb to DEALLOCATE_NORMAL. 
Call FSM_CONVERSATION(R, DEALLOCATE_NORMAL_RC, RCB) (page 5.1-63). 
When BUFFER_ELEMENT type is DEALLOCATE_FLUSH and the verb is DEALLOCATE 
Set RETURN_CODE of the verb to OK. 
When BUFFER_ELEMENT type is DEALLOCATE_CONFIRM, CONFIRM, PREPARE_TO_RCV_CONFIRM, 
or PREPARE_TO_RCV_FLUSH (see Note 2) and the verb is SEND_ERROR 
Call SEND_ERROR_DONE_PROC( transaction program verb parameters, RCB) 
(page 5.1-53). 
Call FSM_CONVERSATION(S, SEND_ERROR, RCB) (page 5.1-63). 
When BUFFER_ELEMENT type is DEALLOCATE_CONFIRM, CONFIRM, PREPARE_TO_RCV_CONFIRM;, 
or PREPARE_TO_RCV_FLUSH, and the verb is DEALLOCATE 
Call COMPLETE_DEALLOCATE_ABEND_PROC( transaction program verb parameters, RCB) 
(page 5.1-30). 
Call FSM_ERROR_OR_FAILURE (page 5.1-65) and pass it a RESET signal (see Note3). 
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FINITE-STATE MACHINES 


FSM_CONVERSATION 


FUNCTION: 


This finite-state machine maintains the status of a conversation resource. 
The states have the following meanings: 


® RESET = conversation initial state, the program can allocate it 


e SEND = the program can send data, request confirmation, or request sync 
point 


RCV = receive, the program can receive information from the remote program 


RCVD_CONFIRM = received confirm, PS received the confirm indicator from 
the HS 


RCVD_CONFIRM_SEND = received confirm send, PS received the confirm send 
indicator from HS 


RCVD_CONFIRM_DEALL = received confirm deallocate, PS received the confirm 
deallocate from HS 


PREP_TO_RCV_DEFER = prepare to receive defer, the program issued a PRE- 
PARE_TO RECEIVE verb with SYNCPT 


DEALL_DEFER = deallocate defer, the program issued DEALLOCATE verb with 
SYNCPT 


PEND _DEALL = pending deallocate, the program issued DEALLOCATE verb with 
CONF IRM 


The inputs are marked with S if they result from an action of the local trans- 
action program and with R if they result from a record sent to PS by HS. The 
RCB is passed to provide the information needed to perform the state transi- 
tion of the FSM_CONVERSATION and its output function. 


PEND_DEALL jis an intermediate state. PS does not return control to the trans- 
action program when the conversation is in this state. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
SEND_DATA_TO_HS_ PROC page 5.1-52 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
FSM_ERROR_OR_FAILURE page 5.1-65 
RCB page A-7 
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FSM_CONVERSATION 
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R» PROGRAM_ERROR_RC 
R, SERVICE _ERROR_RC 


R» DEALLOC_NORMAL_RC 
R, DEALLOC_ABEND_RC 
R, RESOURCE_FAILURE_RC 
R» ALLOCATION_ERROR_RC 


S, DEALLOCATE_FLUSH 
S, DEALLOCATE_CONFIRM 
S, DEALLOCATE_DEFER 
S, DEALLOCATE_ABEND 
S, DEALLOCATE_LOCAL 


R, DEALLOCATED_ INO 


S, GET_ ATTRIBUTES 


OUTPUT FUNCTION | 
CODE 


If data sent by TP is on a logical record boundary then 
Set RCB.PS_TO_HS_RECORD.TYPE to PREPARE_TO_RCV_FLUSH. 
Call SEND_DATA_TO_HS_PROC(RCB) (page 5.1-52). 

Else 

Call DEALLOCATION_| CLEANUP_ PROC (page 5.0-13). 


- 3 Call FSM_ERROR_OR_FAILURE with RESET (page 5.1-65). | 
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FSM_ERROR_OR_FAILURE 
FSM_ERROR_OR_FAILURE 


This finite-state machine remembers if any error or failure records (either 
HS TO_PS_RECORDs or RM_TO_PS_RECORDs) have been received by PS. This Know- 
ledge is maintained until the information reflected by the records can be 
passed to the transaction program. The meanings of the states are as follows: 


© NO_RQS = the initial state of the FSM 
®  RCVD_ERROR = a RECEIVE_ERROR was received 


CONV_FAILURE_PROTOCOL_ERROR = a conversation protocol error record was 
received 


CONV_FAILURE_SON = a session outage notification for the conversation was 
received 


ALLOCATE_FAILURE_RETRY = an allocation failure with retry was received 


ALLOCATE_FAILURE_NO_LRETRY = an allocation failure with no retry allowed 
was received 


SYNCLEVEL_NOT_SUPPORTED = sync level not supported for the conversation is 
signaled 


The inputs are the error and failure records from the HS and RM. 


Referenced procedures, FSMs, and data structures: 


HS page 6.0-3 
RM page 3-18 
RCB page A-7 


STATE NAMES----> 


ALLOCATE 
FAILURE 
NO_RETRY 


CONV 
FATLURE 


SYNCLEVEL 
NOT 
SUPPORTED 


STATE NUMBERS-~-> 


SIGNAL (CONV_FAIL_PROTOCOL ) 
SIGNAL(CONV_FAIL_SON) 


RECEIVE_ERROR 


SIGNAL(ALLOC_FAIL_RETRY) 
SIGNAL( ALLOC_FAIL_NO_RETRY) 


OUTPUT FUNCTION 
CODE 
- | Set RCB.PS_TO_HS_RECORD.DATA to null (purge send buffer). 
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FSM_POST 


FSM_POST 


This finite-state machine maintains the posting status of a conversation. The 
meanings of the states are as follows; 


® RESET = the initial state of the FSM 
®  PEND_POSTED = state after the FSM received a POST_ON_RECEIPT input 


® POSTED = state to show that post conditions were satisfied 


If POST_ON_RECEIPT is issued after posting has already been activated (i.e., a 
prior POST_ON_RECEIPT has been issued), the post conditions used to test for 
post satisfied are reinitialized to those carried in the most recent 
POST_ON_RECEIPT. 


RECEIVE_IMMEDIATE resets posting. If posting is activated and the conversa-~ 
tion has been posted, this FSM is reset. If posting is activated and the con- 
versation has not been posted, posting is canceled and this FSM is reset. 


The initial state of this FSM is RESET. 


STATE NAMES---->[ RESET PENO POSTED 


STATE NUMBERS--> 


POST_ON_RECEIPT [Note 1] 2 [Note 1] 
TEST 1 
WAIT 1 
RECEIVE IMMEDIATE [Note 2] 1 [Note 2) 


SIGNAL( POST ) 
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LOCAL DATA STRUCTURES 


TEST 


TEST contains information that describes the test to be performed on the conversation and 
the result of the test. 


TEST 
RESOURCE: resource identifier 
TEST: possible values: POSTED, REQUEST_TO_SEND_RECEIVED 
RETURN_CODE: possible values: OK, UNSUCESSFUL, POSTING _NOT_ACTIVE 
RESOURCE_FAILURE_RETRY, RESOURCE _FAILURE_NO_RETRY, ALLOCATION_ERROR 
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CHAPTER 5.2. PRESENTATION SERVICES--MAPPED CONVERSATION VERBS 


GENERAL DESCRIPTION 


A Transaction Program (TP) requests LU serv- 
ices by issuing verbs. The verbs request 
several different Kinds of services, and are 
therefore divided into several different cat- 
egories (see SNA Transaction Programmer's 
Reference Manual for LU Type 6.2 for a com- 
plete description of the verbs). Each 
verb-processing component of PS processes the 
verbs of one specific category. Presentation 
Services for Mapped Conversations (PS.MC) is 
the PS component that processes the verbs of 
the mapped conversation category (basic con- 
versation verbs are processed by ''Chapter 
5.1. Presentation Services--Conversation 
Verbs" tn Chapter 5.1). 


PS.MC FUNCTIONS 


The primary function of PS.MC is reformatting 
the data contained in the DATA parameters of 
the MC_SEND_LDATA and MC_RECEIVE_AND WAIT 
verbs. Its subsidiary fumctions include the 
processing of errors related to this refor- 
watting, and the translation of mapped con- 
versation verbs into basic conversation verbs 
in support of services unrelated to format- 
ting. 


When the TP issues a wapped conversation 
verb, PS.MC processes the verb and performs 
the services that it requests. PS.MC does 
not, however, perform all of the services 
requested by every mapped conversation verb. 
PS.MC performs only those services related to 
data formatting. If the verb requests addi- 
tional conversation services that are not 
related to data formatting, then PS.MC, by 
issuing one or more basic conversation verbs, 
causes PS.CONV to perform those services. 


In general, the TP is faced with two format- 
ting problems. The data format that it pre- 
fers for computational processing differs 
from the formats in which data is presented 
to (or by): 


% Local end users and resources 


° Half-sessions (for communication with 
remote end users and resources). 


PS.MC solves the formatting problem for local 
end users and resources by routing all data 
presented to (or by) them through a component 
called "the Mapper" (UPM_MAPPER on page 


The mapped conversation verbs are issued on 
mapped conversations, and basic conversation 
verbs are issued on basic conversations. 
Both the basic and the mapped conversation 
verbs request commmication services for 
transaction programs. A mapped conversation, 
however, is easier for the communicating 
transaction programs to use because it also 
provides data formatting services that the 
programs would have to perform for themselves 
if they were using a basic conversation. 


5.2-46), which transforms data into (when 
receiving) or out of (when sending) formats 
preferred by end users. For communication 
with conversation partners, TP data must be 
made to conform to the format that SNA 
defines for the conversation data stream. On 
basic conversations, the conversing TPs must 
perform this formatting for themselves, but 
on mapped conversations, PS.MC adds (hen 
sending) and strips (when receiving) the 
data-stream details required by the format. 


The functions that PS.MC performs for the 
transaction program are summarized below: 


® Adding and stripping conversation 
data-stream formatting details (see '"'Con- 
versation Data Stream Formatting" on page 
5.2-5) 


¢ Data mapping (see "Data Mapping and the 
Mapper" on page 5.2-8) 


® Allowing function management headers 
(FMHs) to flow on the mapped conversation 
(see "FM Header Data" on page 5.2-7) 


® Detecting service errors committed by 
the partner transaction program (see 
"Service Errors Detected in Received 
Data” on page &.2-163 


® Processing service errors committed by 
the local transaction program = and 
detected by the partner LU (see "Process-~ 
ing of a Service Error Detected by Part- 
ner LU" on page 5.2-17). 
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See "Chapter 5.1. Presentation Services--Conversation Verbs" 
See "Chapter 5.3. Presentation Services--Syne Point Services Verbs" 
See "Chapter 5.4. Presentation Services--Control-Operator Verbs" 
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Note: A dashed line denotes a synchronous (or call/return) protocol boundary between PS components; 
while a solid line denotes an asynchronous (or send/receive) protocol boundary. 


Figure 5.2-1. Overview of Presentation Services, Emphasizing Presentation Services for Mapped 
Conversations 


COMPONENT INTERACTIONS 


In terms of layering, non-basic-conversation sublayer of presentation. services. PS.MC 
verb-processing components (such as PS.MC) communicates primarily with the TP and 
reside below the TP but above the PS.CONV PS.CONV. Figure 5.2-2 on page 5.2-3 illus- 
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Note: 


Figure 5.2-2. 
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See "Component Interactions" on page 5.2-2 for an explanation of the flows 


shown in this figure. 


trates the flow of processing. PS.MC accepts 
issuances of mapped conversation verbs from 
the TP, but issues basic conversation verbs 
to PS.CONV. In both cases, the interaction 
actually occurs indirectly through 
PS.VERB_ROUTER (Chapter 5.0). Whenever a 
verb is issued by any component (for exam- 
ple, the TP), PS.VERB_ROUTER gains control 
and is responsible for routing the verb to 
the appropriate PS component for processing. 


When the TP issues a mapped conversation verb 
(flow 1 in Figure 5.2-2), the verb is 
inspected by PS.VERB_ ROUTER. PS.VERB_ROUTER 
determines that the verb is a mapped conver- 


PS.MC's Use of the Basic Conversation Protocol Boundary 


sation verb and calls PS.MC, passing to it 
the received verb (flow 2). PS.MC may issue 
a basic conversation verb during its process- 
ing of the mapped conversation verb. If it 
does, then PS.VERB_ ROUTER once again gains 
control, receiving the verb issued by PS.MC 
(flow 3). This time, PS.VERB_ROUTER discov- 
ers that the verb is a basic conversation 
verb, so it calls PS.CONV and passes the verb 
to it (flow 4). PS.CONV processes the basic 
conversation verb, after which control 
returns along the same path to PS.MC. 


A transaction program may support only mapped 
conversations or only basic conversations. 
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Alternatively, it may support both types of 
conversation. In the latter case, the trans- 
action program may have mapped conversations 
and basic conversations allocated concurrent- 
ly. The PS.VERB_ROUTER requires the TP to 


PS.MC DATA BASE STRUCTURE 
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In order to perform its functions, PS 
requires information about the transaction 
program that it is serving and about the 
resources currently allocated to that trans- 
action program. This information, which is 
described in "PS.CONV Data-Base Structure" on 
page 5.1-1 , is stored in lists of control 
blocks in the LU (see Appendix A for complete 
definitions of the lists and of the entities 
that may be found in the lists). Some of the 
fields in these control blocks are especially 
important to PS.MC. Those fields are 
described below. 


TRANSACTION CONTROL BLOCK (TCB) 


Each transaction control block (TCB) contains 
information about one execution instance of a 
transaction program. PS.MC identifies the 
TCB describing the particular transaction 
program instance that it is serving by means 
of the TCB_ID that RM passed to PS when the 
transaction program instance was created. 
The TCB fields used by PS.MC contain such 
information as the name of the transaction 
program that PS 1s serving and the LU_ID of 
the LU in which the PS resides. 


LU CONTROL BLOCK (LUCB) 


PS.MC accesses the appropriate LUCB using a 
unique LU_ID, which is stored in the TCB to 
which PS.MC has access. The LUCB fields in 
which PS.MC is particularly interested con- 
tain information about whether the LU sup- 
ports various mapped conversation options, 
such as handling of FM header data. 


Transaction Program Control Block CTPCB) 


Each LUCB also contains a pointer to a list 
of transaction program control blocks 
(TPCBs). For a given LU, the list contains a 
TPCB for each transaction program that is 
capable of running at the LU. The informa- 
tion contained in a TPCB includes the name of 
the transaction program and whether it sup- 
ports various optional features. PS.MC, In 
particular, is interested in whether or not 
the TP supports mapped conversations. 


issue only mapped conversation verbs on 
mapped conversations and only basic conversa- 
tion verbs on basic conversations. However, 
PS.VERB_ROUTER allows PS.MC to issue basic 
conversation verbs on a mapped conversation. 


RESOURCE CONTROL BLOCK (RCB) 


PS.MC also requires information about all the 
mapped conversations allocated to the trans- 
action program. This information is found in 
the resource control block (RCB), one for 
each resource associated with any transaction 
programs running at an LU. As in the case of 
the TCB, PS.MC is interested in only those 
RCBs containing information about mapped con- 
versation resources allocated to its own 
transaction program. It does not need infor- 
mation about resources that are not mapped 
conversations or are allocated to other 
transaction programs. 


PS.MC accesses an RCB by means of the RCB_ID. 
The transaction program supplies an RCB_ID in 
the RESOURCE parameter of a verb in order to 
indicate the particular conversation resource 
on which the verb is being issued. Whenever 
a new resource is allocated, the resources 
manager ("Chapter 3. LU Resources Manager" in 
Chapter 3) creates a new RCB_ID and returns 
it to the transaction program in the RESOURCE 
parameter of the MC_ALLOCATE verb. The RCB 
also contains the TCB_ID of the transaction 
program instance that has allocated the 
resource. RCB information is initialized 
when the conversation is allocated. 


The following RCB fields are especially 
important to PS.MC. : 


MC_MAX_SEND_SIZE contains the length of the 
longest logical record that can be 
sent on the conversation, and is 
used to segment outgoing data (see 
"Construction of GDS Variables" on 
page 5.2-5). 


MAPPER_SAVE_AREA contains information used in 
data mapping, such as the currently 
effective map names (see ‘Map 
Names" on page 5.2-8). The mapper 
may also, however, use data stored 
in this area to perform 
implementation-defined (as opposed 
to SNA-map-name-defined) data map- 
ping. The mapper also uses this 
area to save any error data or 
indicators of events that occurred 
during data mapping. 


MC_RECEIVE_BUFFER contains information that 
has arrived from a_ conversation 
partner but that has not yet been 
received by the transaction pro- 
gram. 
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CONVERSATION DATA STREAM FORMATTING 


When a transaction program sends data on a 
basic conversation, it must ensure that that 
data conforms to the format of the conversa- 
tion data stream. A transaction program that 
allocates a mapped conversation, however, 
does not need to perform this task, because 
PS.MC assumes responsibility for editing the 
data to make it conform to the format of the 
conversation data stream. Transaction pro- 
grams communicating over a mapped conversa- 
tion may supply their data in any format. 


All data flowing on any conversation is for- 
matted into logical records. A_ logical 
record consists of a 2-byte logical record 
length field (LL) followed by a data field. 
A transaction program sending data over a 
basic conversation must take care to include 
the LL fields in its data, and to complete 
the logical record that it ts sending before 
leaving SEND state. 


A TP sending data over a mapped conversation 
has neither of these concerns, because PS.MC 
computes and inserts the LLs for it. The TP 
simply supplies the data in the DATA parame- 
ter of MC_SEND_DATA. PS.MC then maps the 
data and formats the mapped data into one or 
wore complete logical records. 


CONSTRUCTION OF GDS VARIABLES 


PS.MC formats all data flowing on a mapped 
conversation into general data stream (6DS) 
variables (see Figure 5.2-3). A 605 variable 
consists of one or more complete logical 
records. The data field of the first logical 
record in a 6DS variable begins with a 2-byte 
GDS ID that identifies the type of informa- 
tion contained in the variable. The informa- 
tion itself begins in the third byte of the 
data field of the first logical record, and 
continues throughout the data fields of the 
variable's remaining logical records, which 
do not contain the 6D5 ID. 


6DS Variable 
(Consisting of 1 Logical Record) 


ce Teso [aw 


Logical Record 
a 


GDS Variables and Logical 
Records 


Figure 5.2-3. 


The following types of GDS variables flow on 
mapped conversations: 
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Map Nane 
Application Data 
User Control] Data 
Error Data 

Error Log 

Null Data 


e@0e@:@ 8 @ 6 


(See Appendix H for descriptions of all the 
valid types of GOS variables and their 6DS ID 
values.) 


Map Name 60S variables are generated from the 
MAP_NAME parameter of MC_SEND_DATA (see ''Map 
Names" on page 5.2-8 for details). Applica- 
tion Data and User Control Data GDS variables 
(collectively called data GDS variables) are 
generated from data supplied via the DATA 
parameter of MC_SEND_ DATA. If this verb is 
issued with FMH_DATACYES), the data is put 
into a User Control Data 6DS variable; other- 
wise, it is put into an Application Data GDS 
variable. Error Data GDS variables are gen- 
erated when the TP issues MC_SEND_ERROR or 
when PS detects an error (see "Mapped Conver- 
sation Errors" on page 5.2-12 for details). 


Null Data 60S variables are optionally gener- 
ated when the TP, after entering SEND state, 
leaves SEND state without sending any data. 
(Instead of issuing WMC_SEND_DATA, the TP 
issues MC_CONFIRM, MC_PREPARE_TO_RECEIVE, or 
some other verb that removes the TP from SEND 
state.) The partner must be notified of 


this change in state. The RH that conveys 
this state-change notification (CD for 
MC_PREPARE_TO_RECEIVE, or RQD2 for 


MC_CONFIRM) can flow to the partner by means 
of a null-data FMD request, a LUSTAT request, 
or a Null Data GDS variable created by PS.MC. 
An Application Data GDS variable pith a null 
data field cannot be used for this purpose, 
because that would erroneously indicate that 
the TP had issued MC_SEND_DATA with 
LENGTH(0), when the TP has not. issued 
MC_SEND_DATA at all. 


60S Variables with Multiple Logical Records 


Only data 6DS variables may consist of multi- 
ple logical records; Error and Map Name GDS 
variables each consist of a single logical 
record. Whether a data GDS variable will 
have more than one logical record is deter- 
mined by the value of MC_MAX_SEND_SIZE, which 
is the length of the longest logical record 
that may be sent on the mapped conversation. 
MC_MAX_SEND_SIZE may vary from mapped conver- 
sation to mapped conversation, or it may be 
the same for all wmapped = conversations. 
MC_MAX_SEND_SIZE is stored in the resource 
control block associated with the conversa- 
tion (see "PS.CONV Data-Base Structure" on 
page §.1l-1 and "PS.MC Data Base Structure" 
on page 5.2-4 for further details). 


If the length of the data returned from the 


mapper does not exceed MC_MAX_SEND_SIZE, 
PS.MC creates a 60S variable containing a 
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GDS variable containing multiple logical records 


* This data is supplied by the transaction program in an MC_SEND_DATA verb. 


Note: 


The DATA field of the first, or only, logical 


record in a GDS variable begins with a 2-byte 


GDS ID. Subsequent logical records in the same GDS variable do not carry a GDS ID value. 


Figure 5.2-4. 
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Single logical record. MC_MAX_SEND_SIZE is 
used only to determine how many logical 
records to create from the data; it is not 
used to determine whether enough data exists 
to be sent to the partner LU. (See Fig- 
ure 5.2-4.) 


If PS.MC determines that multiple logical 
records are required, the LL fields of all 
but the last logical record have the 
high-order bit turned on to indicate that 
the data is continued in the next logical 
record. PS.MC continues to create logical 
records containing data returned from the 
mapper until the end of the data is reached. 
The high-order bit of the LL field of the 
last logical record in the outgoing GDS vari- 


Transformation of Data from MC_SEND_DATA to a GDS Variable 


able is turned off by the mapper. Fig- 
ure 5.2-4 illustrates the transfer of 
outgoing data from its beginning in the DATA 
parameter of MC_SEND_DATA to its final posi- 
tion in a logical record in a GDS variable. 


When the TP is receiving data, this process 
is reversed. PS.MC continues to receive data 
from PS.CONV until it receives a logical 
record in which the high-order bit of the LL 
field is off. At this point, PS.MC has a 
complete data GDS variable. Next, PS.MC 
strips the GDS ID and Lls from the received 
data,» and maps the data according to the cur- 
rently effective map name. The mapped data 
goes into application transaction program 
variables. 
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In either case, exactly one data 6DS variable 
is created as a result of each issuance of 
MC_SEND_DATA, and exactly one 6DS variable is 
received as a result of each issuance of 
MC_RECEIVE_AND_WAIT. 


Fit HEADER DATA 


In LU 6.2, FM header data is normally proc- 
essed by PS rather than by the transaction 
program. All FMHs except FMH-5 (to initiate 
a conversation) and FMH-7 (to report a PS or 
transaction program error) are trapped as 
errors. In LU 6.1, however, an FMH-5 could 
be used for transaction program functions 
(for example, transaction program parameters 
were sometimes encoded in an FMH-5), and 
could flow at any time during a conversation. 
Therefore, in order to allow transaction pro- 
grams that were written for LU 6.1 to run on 
LU 6.2, PS.MC provides a way for transaction 


EXAMPLES OF MAPPED CONVERSATION VERB PROCESSING 


As discussed in "PS.MC Functions" on page 
5.2-1, one function of PS.MC is to translate 
mapped conversation verbs and their parame- 
ters into basic conversation verbs and param- 
eters (the other functions relate 
specifically to the mapping of data). The 
functions of PS.MC that relate to verb trans- 
lation are illustrated and described below. 
(The data-mapping-related functions are 
described in detail in "Data Mapping and the 
Mapper" on page 5.2-8.) 


ESTABLISHING A MAPPED CONVERSATION 


A mapped conversation is established when the 
transaction program issues MC_ALLOCATE. 
PS.MC, upon receipt of MC_ALLOCATE from the 
transaction program, performs some initial 
processing. If the processing succeeds, then 
PS.MC issues the basic conversation verb 
ALLOCATE, with TYPE(MAPPED_CONVERSATION), to 
-PS.CONV. PS.CONV copies the supplied TYPE 
value into the Resource Type field in the 
FMH-5 that it creates as a result of the 
ALLOCATE. Then, after completing its normal 
ALLOCATE processing, returns control to 
PS.MC. 


When the FMH-5 arrives at the target LU, it 
causes the conversation partner transaction 
program to be attached for invoked). When 
the partner program is attached, it is only 
for the mapped conversation with the trans- 
action program that has just invoked it. It 
may, however, request additional mapped con- 
versations by issuing MC_ALLOCATE verbs of 
its own. 


Once PS.MC returns control to the transaction 
program after processing of the MC_ALLOCATE 


programs to prevent PS from intercepting the 
FM header data that they are trying to 
exchange. 


If the TP wants to send application data con- 
taining FM headers to its partner, the TP 
issues MC_SEND_DATA with FMH_DATACYES). This 
causes PS.MC to create a User Control Data 
GDS variable to contain the data. When FM 
header data is contained in a User Control 
Data GDS variable, the sending PS and the 
receiving PS do not process it; they allow it 
to flow directly to the receiving TP. PS.MC 
notifies the receiving TP of the presence of 
FM headers in the received data on the 
MC_RECEIVE_AND_WAIT verb (see SNA Transaction 
Programmer's Reference Manual for LU Type 
6.2) that the receiving TP tssues to receive 
the data. 


Currently, the sole use of User Control Data 
GOS variables on mapped conversations is this 
processing of FM header data. 


is complete, the transaction program may 
issue mapped conversation verbs on the con- 
versation whose ID was returned in the 
RESOURCE_ID parameter of the MC_ALLOCATE. 


PS.VERB_ROUTER prohibits the transaction pro- 
gram from issuing basic conversation verbs 
specifying the resource ID of this mapped 
conversation. When the transaction program 
issues a mapped conversation verb, however, 
PS.VERB_ROUTER allows PS.MC, as part of its 
processing of that verb, to issue a basic 
conversation verb on the same mapped conver- 
sation. See Chapter 5.0 for a further dis- 
cussion of this topic. 


TERMINATING A MAPPED CONVERSATION 


When the transaction program determines that 
its processing related to a mapped conversa- 
tion has completed, or that the mapped con- 
versation should be ended for other reasons, 
it causes the conversation to be terminated 
by issuing MC_DEALLOCATE. PS.MC processes 
this by issutng DEALLOCATE to PS.CONV. How- 
ever, if the MC_DEALLOCATE specified a deal- 
location type of ABEND (see SNA Transaction 
Programmer's Reference Manual for LU Type 
6.2), PS.NC first translates the ABEND value 
to ABEND_PROG before setting the type of 
deallocation. This reflects the fact that it 
is the transaction program, rather than 
PS.MC, that caused the DEALLOCATE to be 
issued. For all other types of deallocation, 
PS.MC sets the TYPE field of the DEALLOCATE 
to the value specified in that field of the 
MC_DEALLOCATE. _ 
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The. transaction program sends data to its 
partner by issuing MC_SEND_DATA. The partner 
transaction program receives this data by 
issuing MC_RECEIVE_AND_WAIT. Whenever PS.MC 
processes either of these verbs, it passes 
the data through a component called the 
mapper (page 5.2-46). All mapped conversa- 
tion data is thus mapped twice: once when 
sent, and once when received. PS.MC's proc- 
essing of MC_SEND_DATA is’ called = send 


mapping; its processing of 
MC_RECEIVE_AND_WAIT 1s called receive 
mapping. The particular mappings that the 


mappers perform are determined by the map 
name supplied by the sending transaction pro- 
gram. 


BLOCK MAPPING 


PS.MC performs block mapping, where a block 
is the amount of data contained in one data 
GDS variable (see “Construction of GDS Vari- 
ables" on page 5.2-5 for definitions and 
descriptions of GDS variables). Typically» a 
data GDS variable (or block) resides in a 
transaction program buffer variable dedicated 
to network communication. The ultimate 
source or destination of the data, however, 
is usually one or more other transaction pro- 
gram variables that are significant to the 
transaction program application. A map pro- 
vides an algorithm for transferring data 
between transaction program application vari- 
ables and the transaction program buffer var- 
iable, and for performing any changes in the 
format or representation of the data that 
this transfer may require. Thus, in receive 
mapping, the received data is mapped out of a 
block and into application variables, while 
in send mapping, the data is mapped out of 
application variables and into a block before 
being sent to the conversation partner. 


MAPPING EXAMPLF 


Figure 5.2-5 on page 5.2-9 shows a high-level 
overview of the transformations that map name 
and data undergo during mapping by the send- 
ing and receiving transaction programs. Map- 
ping is symmetric, in that receive mapping is 
basically the inverse of send mapping. 


The transaction program sending data on a 
mapped conversation supplies a map name with 
each issuance of MC_SEND_DATA. The map name 
supplied by the sending transaction program 
determines the Kind of mapping that occurs. 
In the figure, transaction program A issues 
MC_SEND_DATA, supplying MAP_NAME(map-name-1 ) 
and DATA(data-1). PS.MC, as part of its 


processing of this verb, then invokes the | 


mapper. PS.MC passes to the 
map-name-1 and data-1l. 


mapper 


The output from the mapper is map-name-2 and 


data-2. Data-2 may be a different size from 


data-1 and may be in an entirely different 
format. After reformatting data-2 into a GDS 
variable (by breaking it into logical records 
according to MC_MAX_SEND_SIZE, and prefixing 
a GDS ID), PS.MC sends map-name-2 and data-2 
to the partner LU. 


When the data arrives, the PS.MC component at 
the partner LU processes the 
MC_RECEIVE_AND_WAIT by repeatedly issuing 
RECEIVE_AND_ WAIT with a fill value of LL. 
PS.MC accumulates the data, one logical 
record at a time, until it receives a logical 
record whose LL field indicates that it is 
the final logical record of the incoming data 
GDS variable. At this point, PS.MC has one 
complete data GDS variable. It then strips 
the GDS ID and LLs» and invokes the mapper, 
passing it map-name-2 and data-2. Here, at 
the receiving LU, the map name and data once 
again go through a_ transformation. The 
receiving mapper transforms map-name-2 and 
data-2 into map-name-3 and data-3, and 
returns these to the receiving transaction 
program in the MAP_NAME and DATA parameters 
of MC_RECEIVE_AND WAIT (only the amount of 
data requested by the transaction program is 
passed to it; any remaining data that is not 
requested and returned is discarded). Data-3 
may again differ in size and format from 
data-2, or from data-1. Map-name-3, similar- 
ly, may be different from map-name-2 and 
map-name-1. In the simplest case, the three 
map names are identical. 


"Send Mapping" on page 5.2-10 "Receive Map- 
ping" on page 5.2-11 show more details of the 
processing of MC_SEND_DATA and 
MC_RECEIVE_AND_WAIT. 


MAP NAMES 


With every issuance of MC_SEND_DATA, the 
transaction program supplies a map name to 
PS.MC and the mapper. Similarly, on every 
issuance of MC_RECEIVE_AND_WAIT, the mapper 
returns a map name to the transaction pro- 
gram. The sending transaction program may 
supply the same map name repeatedly, and the 
Same map name may be received repeatedly by 
the receiving transaction program, but the 
sending PS.MC does not send consecutive 
duplicate map names. Instead, the locally 
Known map name supplied by the transaction 
program 15 translated into a globally Known 
map name and stored in the MAPPER_SAVE_AREA 
as the currently effective map name. This 
map name is similarly stored by the receiving 
PS.MC. The. sending PS.MC sends (and the 
receiving PS.MC receives) a new map name only 
when the currently effective map name 
changes. The currently effective map name 
changes when the map name supplied by the 
sending transaction program is translated 
into a globally Known map name that differs 
from the currently effective one stored in 
the MAPPER_SAVE_AREA. When the mapper dis- 
covers this difference, it updates the cur- 
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TP(A) 


Map-name-1l and data-1 


(Sending LU) 
PS .MC 
(UPM_MAPPER ) 


map-name-1, data-1 


(Receiving LU) 
PS .MC 
(UPM_MAPPER ) 


TP(B) 


map-name-2, data-2 


are supplied by the sending transaction program on MC_SEND_DATA. 
and data-2 flow from sending PS.MC to receiving PS.MC as GDS variables. 


map-name-3, data-3 


Map-name-2 | 
Map-name-3 and data-3 are 


passed to the receiving transaction program via MC_RECEIVE_AND WAIT . 


See "Mapping Example" for an explanation of the flows shown in this figure. 


Figure 5.2-5. An Example of Mapping 


rently effective map name in its 
MAPPER_SAVE_AREA, and inforws PS.MC of this 
change by returning an indicator and the new 
map name. 


The mapper can translate map names in many 
different ways. It may, for example, trans- 
late the supplied map name to null, thereby 
preventing the data from being transformed. 
The mapper may also translate two different 
locally knonn map names to the same globally 
known map name. For instance, if the trans- 
action program issues MC_SEND_DATA with map 
name A followed by another MC_SEND_DATA with 
map name B, the mapper may map both map names 
to map name C. Moreover, the mapper may 
translate the same locally Known map name 
differently on different occasions. If the 
transaction program issues MC_SEND_DATA with 
wap name A and the mapper translates it to 
map name B, then when the transaction program 
again issues MC_SEND_DATA with map name A, 
the mapper may, because of information known 
only to itself, translate this map name to 
wap name C. Nevertheless, the translation of 
map names by the mapper 1s subject to some 
constraints. For example, the mapper never 
translates a null map name to a nonnull map 
name. 


Map Name 6DS Variables 


To complete its processing of a change in the 
effective map name, the sending PS.MC must 
notify the receiving PS.MC of the change. It 
does this by sending to the receiving PS.MC a 
Map Name GDS variable containing the new 
effective map name. In this situation, a 
single MC_SENOD_DATA causes two GDS variables 
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to be created: a Map Name GDS variable and a 
data GDS variable. 


Similarly, the receiving mapper saves, in its 
MAPPER_SAVE_AREA, the map name received in a 
Map Name 6DS variable. When subsequent data 
GOS variables are received with no interven- 
ing Map Name GOS variables, the mapper uses 
the saved map name in mapping the new data. 
Once a Map Name GDS variable is received, 
that map name remains in effect until another 
map name is received or the mapped conversa- 
tion ends. 


When the effective map name is null Cmwith a 
length of zero), mapping is said to be "off"; 
that is, any data passed to the mapper is 
returned unchanged. At the beginning of all 
mapped conversations, the effective map names 
are initialized to null. This happens prior 
to any flow of Map Name GDS variables. A Map 
Name GOS variable containing a null map name 
is sent to the partner only to change the 
effective map name back to null after it has 
not previously been null. If the transaction 
program always supplies a null map name, no 
Map Name 605 variable is evar sent to the 
partner LU. 


MAPPER INVOCATION 


PS.MC invokes the mapper whenever any of the 
following occurs: 


® The transaction program sends or receives 
data (that is, issues MC_SEND_DATA or 
MC_RECEXVE_AND WAIT). The data may be 
application data or FM header data; both 
of these types of data may be mapped. 
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® PS.MC receives, from PS.CONV, information 
indicating that the partner transaction 
program has received and processed all 
the recently sent = map names. This 
includes information such as a positive 
reply to CONFIRM or to SYNCPT; or any 
information that the partner transaction 
program issued from SEND 
explanation below). 


The mapper is also invoked during the error 
processing triggered by the events listed 
below. This processing is more thoroughly 
described in "Mapper Errors" on page 5.2-12. 
e 8=6=s-C The transaction issues 
MC_SEND_ERROR. 


program 


e  PS.MC issues SEND_ERROR with a type value 
of SVC (see SNA Transaction Programmer's 
Reference Manual for LU Type 6.2). 


® The transaction program or the sync point 


manager ("Chapter 5.3. Presentation Serv- 
ices--Syne Point Services Verbs") issues 
BACKOUT. 


e A return code of SVC_ERROR_* is received 
from PS.CONV. 


e 636A return code of PROG_ERROR_* is received 
from PS.CONV. 


A positive reply to CONFIRM or to SYNCPT 
informs the mapper that any map names it has 
caused to be sent to the partner have been 
received and processed by it. For example, 
if the mapper causes a Map Name GDS variable 
to be sent to the partner LU, and is informed 
that a positive reply to CONFIRM has been 
received, and is next invoked because the 
partner LU detected an error while in RECEIVE 
state, the mapper Knows, because of the 
intervening confirmation, that the error 
processing at the partner did not cause the 
map name to be purged. The mapper does not 
cause a duplicate map name to be sent in this 
case. 


In addition, receipt of data from the partner 
also indicates that all the recently sent map 
names have been processed, because the part- 
ner cannot have sent data unless it has 
entered SEND state, and it cannot have 
entered SEND state (from RECEIVE state, which 
is the state it was in when it was receiving 
and processing the data sent by the trans- 
action program) unless) it has’ finished 
receiving and mapping all the data that the 
transaction program. was sending. Moreover, 
not only receipt of data, but receipt of any 
information whatsoever that the partner 
issued from SEND state (such as a SEND indi- 
cator, CONFIRM, or even an error notifica- 
tion) indicates to the mapper that the 
partner has received and processed the most 
recently sent map names. | | | 


MAPPER PARAMETERS 


Each time PS.MC invokes the mapper, it sup- 
plies required information to the mapper. 


state (see. 


This information includes, in addition to the 
map name and the data to be mapped, such 
information as whether send or receive map- 
ping is to be performed. Also, based upon 
the reason for the mapper invocation, infor- 
mation may be returned by the mapper to 
PS.MC. The mapper also uses other data 
structures in the RCB to store currently 
effective map names and incoming data. The 
information used and returned by the mapper 
is listed below. For a further description 
of mapper input and output, see the formal 
description of the UPM_MAPPER on page 5.2-46. 


Supplied Information 


® Reason for the mapper invocation 
- Data mapping 
~ Errors 
- Positive confirmation 
e Data polarity 
- Send 
- Receive 
® FMH data indicator 
e Input map name 
® Input data 


e Error code 


Returned Information 


Output map name 


Output data (mapped data) 


© Mapper return code 
SEND MAPPING 


When the transaction program is sending data 
(i.e., when PS.MC is processing 
MC_SEND_DATA), the mapper is responsible for: 


e Mapping the data supplied by the trans- 
action program (in the verb's DATA param- 
eter) in accordance with the MAP_NAME 
parameter supplied by the transaction 
program 


® Mapping the locally Known map name sup- 
plied by the transaction program to a 
globally known map name corresponding to 
the format of the mapped data 


® Determining whether to send a Map Name 
GDS variable to the partner LU, and pre- 
venting duplicate Map Name GDS variables 
f;om flowing consecuxively to the partner 
LU 
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e Determining whether to resend a Map Name 
GDS variable to the partner LU, in the 
event of an error | 


PS.MC's processing of  MC_SEND_DATA i) 
described below. For example, the trans- 
action program issues MC_SEND_DATA with 
MAP_NAME(A) and DATA(data-1). PS.MC invokes 
the mapper, informing it that send mapping is 
to be performed. PS.MC also passes to the 
mapper the supplied map name and data. 


The mapper translates map name A to map name 
B and maps data-1 to data-2, to be sent to 
the partner LU. The translated map name, 
since it differs from the currently effective 
map name (which 1S stored in the 
MAPPER_SAVE_AREA and is initially null) is 
returned to PS.MC. The translated data is 
also returned. 


When control is returned to PS.MC from the 
mapper call, PS.MC first determines whether 
the mapper succeeded in mapping the supplied 
data Cit could have failed if the trans- 
action program had provided a map name 
unknown to the mapper). Since the mapping 
was successful, PS.MC next determines whether 
a new map name has been returned. In this 
case, the mapper has returned the output map 
name, because the translated map name B dif- 
fers from the currently effective map name. 
Therefore, PS.MC updates the currently effec- 
tive map name to B and creates a Map Name GDS 
variable (to be sent to the partner) contain- 
ing map name B. PS.MC next formats the data 
returned by the mapper as a an Application 
Data or User Control Data GDS variable, by 
segmenting it into logical records and pre- 
fixing the GDS ID. PS.MC uses the 
MC_MAX_SEND_SIZE field in the RCB to deter- 
mine the size of the logical records. 


Finally, PS.MC issues SEND_DATA, with a DATA 
parameter containing the Map Name and data 
GDS variables. When the SEND_DATA completes 
successfully, PS.MC returns control to the 
transaction program, indicating that the 
MC_SEND_DATA was also successful. 


When the transaction program again issues 
MC_SEND_DATA, again specifying a map name of 
A, PS.MC again invokes the mapper. As in the 
previous invocation, the mapper translates 
map name A to map name B. Since it has 
already caused PS.MC to send map name B to 
the partner LU, it does not return an output 
map name to PS.MC. 


Since no map name was returned from the 
mapper, PS.MC does not create a Map Name GDS 
variable. It processes the output data as 
above, creating an Application Data or User 
Control Data GDS variable containing the 
data. Finally, it issues SEND_DATA with a 
DATA parameter containing only the data GDS 
variable. An OK return cede is returned on 
the SEND_DATA, and PS.MC returns a return 
code of OK on the MC_SEND_DATA. 


RECEIVE MAPPING 


When the transaction program is receiving 
data (i.e., when PS.MC iS _ processing 
MC_RECEIVE_AND_WAIT), the mapper is responsi- 
ble for 


e Mapping the data received from the part- 
ner LU in accordance with the currently 
effective map name, 


e Mapping the currently effective map name 
to a locally Known map name corresponding 
to the format of the mapped data, and 
returning this map name and the mapped 
data to the transaction program, and 


® Optionally, checking incoming Map Name 
GDS variables from the partner LU for 
duplication and symbol-string consisten- 
cy. 


An example of PS.MC's processing” of 
MC_RECEIVE_AND_WAIT is described below. 


First, PS.MC issues the basic conversation 
verb RECEIVE _AND_WAIT to PS.CONV, specifying 
a fill value of LL (see SNA Transaction Pro- 
grammer's Reference Manual for LU Type 6.2) 
to request that PS.CONV return one logical 
record. After the RECEIVE_AND_WAIT completes 
successfully, PS.MC finds that the data 
received consists of a Map Name GDS variable. 
Knowing that a data GDS variable is to follow 
the map name » PS .MC again issues 
RECEIVE_AND_WAIT to PS.CONV, again retriev- 
ing one logical record. The data received in 
the second RECEIVE_AND_WAIT is application or 
FM header data, but the high-order bit of the 
LL field in the logical record indicates that 
more data follows that is to be associated 
with the data just received; that is, the 
data GDS variable consists of multiple log- 
ical records (see "Construction of GDS Vari- 
ables" on page 5.2-5). PS.MC continues to 
request data from PS.CONV until ~~ the 
high-order bit of the LL field of the 
received logical record is off, indicating 
that the entire data GDS variable has been 
received. In the example, this occurs on the 
third RECEIVE _AND_WAIT. 


PS.MC has now received a map name and data to 
be mapped. It invokes the mapper == and 
receives from the mapper the map name and 
mapped data to be passed to the transaction 
program. PS.MC passes to the transaction 
program the amount of data that the trans- 
action program has requested, and discards 
any remaining data. 


MC_TEST PROC 


An implementation of the mapped conversation 
verbs includes an entry point, MC_TEST_PROC; 
which can be used to determine whether a com- 
plete data GDS variable has been received 
from the remote TP without causing the call- 
ing program to wait if data is not available 
immediately. This entry point is called by 
the implementation of the WAIT verb, which 
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calls 


enables a TP to wait for arrival of data on 
any of a list of kasic and mapped conversa- 
tions. 


An MC_POST_ON_RECEIPT verb must be issued 
before a call to MC_PROC_TEST is effective. 
Thus, MC_POST_ON_RECEIPT must be issued 
before a WAIT verb that includes a mapped 
conversation in its list. Then a sequence of 
can be made to MC_TEST_PROC, which 
returns the code OK when a complete data GDS 
variable 1s available. 


In order to determine whether a complete data 
GDS variable has been received from the 
remote TP, MC_TEST_PROC has to issue a 
RECEIVE_AND_WAIT verb, so that it can examine 
the data. Several RECEIVE_AND_WAIT. verbs may 
be required before a complete data GDS vari- 
able is received. As the pieces of the data 
GDS variable are received, they are placed in 
an RCB field, MC_RECEIVE_BUFFER, where they 
are held until the local TP issues an 
MC_RECEIVE_AND_WAIT verb. 


To make sure that the RECEIVE _AND_WAIT verbs 
that it issues do not cause waits for data to 
be received from the remote TP, MC_TEST_PROC 
calls a similar entry point of PS.CONV; 
TEST_PROC, to determine whether a logical 
record has already been received. Only when 
such a record is available does it issue a 
RECEIVE_AND_WAIT verb. 


An example of the use of MC_TEST_PROC is 
illustrated in Figure 5.2-6 on page 5.2-13 
and described below. This figure begins with 
the TP issuing an MC_POST_ON_RECEIPT verb for 
a specified mapped conversation. It then 
issues a WAIT verb, which causes’ the 
PS.VERB_ROUTER to call MC_TEST_PROC for the 
specified conversation, as well as others. 
MC_TEST_PROC first checks the 
MC_RECEIVE_BUFFER in the RCB associated with 
the conversation to see if it holds a com- 
plete data GDS variable. 
PS.MC does not have a data GDS variable 
ready. Therefore, MC_TEST_PROC calls 
TEST_PROC to determine whether PS.CONV has 
any data ready to be received. PS.CONV 
returns to PS.MC with a code indicating that 
data is available, |= WHAT RECEIVED = 
DATA_COMPLETE. PS.MC issues RECEIVE_AND_WAIT 
to retrieve the waiting data. After inspect- 
ing the data, PS.MC discovers that it is not 
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MAPPER ERRORS 


In send mapping, the supplied map name is not 
checked for symbol-string consistency; its 
symbol-string restrictions, if any» are 
implementation-defined. The mapper trans- 
lates the supplied map name to a globally 
Known map name that conforms to the 
symbol-string definitions in the SNA Trans- 
action Programmer's Reference Manual for LU 
Type 6.2. 


In this example, § types of information. 


SEND indicator, 


PS.MC, therefore, also performs no 


sufficient to complete the current data GDS 
variable. PS.MC stores the received data in 
MC_RECEIVE_BUFFER, issues POST_ON_RECEIPT to 
request that PS.CONV reinitiate posting, and 
returns the code UNSUCCESSFUL to 
PS.VERB_ROUTER. PS.VERB_ROUTER resumes test- 
ing this resource and all others specified in 
the WAIT verb for receipt of a complete data 
GDS variable. : 


In this example, had the call to TEST_PROC 
returned any code other than OK--DATA, PS.MC 
would not issue RECEIVE_AND_WAIT but would 
return to PS.VERB_ROUTER the same code that 
it received from TEST_PROC. On the other 
hand; had the data returned by 
RECEIVE_AND_WAIT completed a data GDS vari- 
able, MC_TEST_PROC would not have issued 
POST_ON_RECEIPT but would have returned the 
code OK--DATA to PS.VERB_ROUTER. 


When MC_TEST_PROC is called, 
MC_RECEIVE_BUFFER is in one of the following 
states: 


® It is empty. 

e It contains the initial logical records 
of a data GDS variable (perhaps preceded 
by an associated map name GDS variable), 
but does not yet contain the remaining 
logical records of the data GDS variable, 
which must be received before the data 
can be passed to the transaction program. 

e It contains a complete data GDS variable 
that is ready to be mapped and passed to 
the transaction program. 


Once a complete data GDS variable has been 
received, PS.MC requests no more information 
from PS.CONV until it passes to the trans- 
action program the data already in 
MC_RECEIVE_BUFFER. 


MC_RECEIVE_BUFFER may contain many different 
It may contain tran- 
sient information, such as a return code or a 
which is returned to the 
transaction program as soon as processing of 
the current verb is completed. It may con- 
tain part or all of a data GDS variable. 
These logical records remain in the list 
until the incoming data GDS variable is com- 
plete and is retrieved by RECEIVE_AND_WAIT. 


checking of the globally known map name 
returned by the mapper; the mapper is respon- 
sible for supplying map names that conform to 
SNA-defined formats. In receive mapping,» 
however, the mapper does check the map name 


received in a Map Name GDS variable for 
symbol-string consistency. The mapper 
informs PS.MC via ae- return’ code of 


MAP_NOT_FOUND when the map name violates 


SNA-defined symbol-string types, or when the 


map name conforms to defined symbol-string 
types but is unknown to the mapper (see 
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TP PS .VERB_ROUTER PS.MC PS .CONV 


MC_POST_ON_RECEIPT POST_ON_RECEIPT (FILL = LL) 


> NNN SEW My SOY DANN atten sao, seemsesepenemmemmnntaeeamnesmeesS 


WAIT Call MC_TEST_PROC 
Teena a | eR SR ER AEA SP 


MC_RECEIVE_BUFFER does not hold 
a complete data GDS variable 


Call TEST_PROC 
return code = OK~--DATA 


PS.CONV has data 


RECEIVE_AND_WAIT (FILL = LL) 
PSE Se Rane ane ORO ee en ne ene me Se 


WHAT_RECEIVED = DATA_COMPLETE 
<— ee 


More Data to be Received. 
POST_ON_RECEIPT (FILL = LL) 
return code = UNSUCCESSFUL 
Continue testing for posting by 
any resource specified in the verb 
See "MC_TEST_PROC" on page 5.2-11 for an explanation of the flows shown in this figure. 


Note: Only those parameters pertinent to the example are shown. 


| Figure 5.2-6. MC_TEST_PROC 


If notification of an error is received and 
the mapper has previously caused PS.MC to 
send a map name to the partner LU, the mapper 


Appendix H for definitions of the valid 
symbol-string types). 


The mapper also performs an optional receive 
check to determine if it has received a map 
name that is the duplicate of the map name 
last received. If it has, then the mapper 
informs PS.MC, which ends the mapped conver- 
sation. See "Protocol Violations" on page 
5.2-14 for details. 


If notification of an error is received, 
PS.MC passes the error notification to the 
transaction program as a return code. In 
addition, PS.MC invokes the mapper to inform 
it of the error. The mapper then determines 
whether a map name needs to be re-sent, since 
the MC_SEND_ERROR issued by the partner 
transaction program or PS.MC might have 
caused the map name to be purged on receipt. 


checks to see if any information has been 
received that would indicate that the partner 
LU has received and processed the map name. 
Examples of the type of information that 
would indicate this are an affirmative reply 
to CONFIRM or to SYNCPT, received data, or a 
SEND indicator. If none of the above has 
been received, the mapper causes a map name 
to be re-sent to the partner LU. The map 
name that is sent is based upon the map name 
supplied by the transaction program on the 
next MC_SEND_DATA. 


The mapper needs to be informed of any errors 
that occur on a mapped conversation, and of 
any issuances of BACKOUT that occur on a 
mapped conversation whose synchronization 
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5.2-14 


level is SYNCPT, because these events may 
require the mapper to re-send the currently 
effective map name. In the case of an error 
detected by the partner LU, a map name that 
the mapper has sent to the partner may have 
been purged by the partner as a result of its 
error processing. Therefore, the mapper has 
to determine whether it needs to re-send the 
map name that may have been purged. In the 
case of BACKOUT, the entire mapped conversa- 
tion is required to revert to the status it 
had at the last issuance of SYNCPT. If the 
currently effective map name has changed 
Since then, the mapper needs to resend the 
map name that was in effect at the last issu- 
ance of SYNCPT. 


ERROR DATA GDS VARIABLES 


A GDS variable that is not created as a 
direct result of action taken by the trans- 
action program is the Error Data GDS vari- 
able. When PS.MC detects an error in the 
data being received from the partner LU- it 
issues a SEND_ERROR TYPE(SVC) followed by a 
SEND_DATA. The PATA parameter of the 
SEND_DATA eertains the Error Data GDS vari- 
able. wnich describes the exact nature of the 
error encountered. The transaction program 
serviced by the PS.MC that received the data 
and detected the error is not informed of the 
error. The transaction program that issued 
the data in which an error was found is told 
of the error via a return code derived from 
the information contained in the Error Data 
GDS variable (see "Processing of a Service 
Error Detected by Partner LU" on page 
5.2-17).* An example of the type of error 
that PS.MC might encounter in received data 
is receipt of a User Control Data GDS vari- 
able when FM header data is not supported by 
the transaction program or the LU. 


PROTOCOL VIOLATIONS 


PS.MC performs optional receive checks to 
determine if the partner LU has committed a 
protocol violation. An example of a protocol 
violation PS.MC can detect is the receipt of 
a Map Name GDS variable followed by something 
other than a data GDS variable (map names 
have to be followed by data). 


When PS.MC detects a protocol violation such 
as the one above, it issues DEALLOCATE with 
TYPE(ABEND_SVC) and returns a return code of 
RESOURCE_FAILURE_NO_RETRY to the transaction 
program. Correspondingly» when PS .MC 
receives a return code of DEALLO- 
CATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER from 
PS.CONV, it translates the return code to 
RESOURCE_FAILURE_NO_RETRY, and passes it to 
the transaction program. 


If, however, the protocol violation occurred 
because the mapped conversation ended prema- 
turely at the partner LU (i.e., the partner 
LU has issued a deallocation notification 
that indicates a protocol error), then PS.MC 
simply logs the error and passes the 


RESOURCE_FAILURE_NO_RETRY return code to the 
transaction program. Since the mapped con- 
versation has already been deallocated at the 
partner LU, PS.MC cannot issue the DEALLOCATE 
(TYPE=ABEND_SVC) that it normally issues when 
it detects a protocol violation. 


SERVICE ERRORS 


The TP, upon detecting an error on a mapped 
conversation, issues MC_SEND_ERROR with 
TYPE(PROG). This indicates that the type of 
error detected was a program error (1.@.5 was 
an error discovered by a TP). Another cate- 
gory of errors may be detected by the LU 
rather than the TP. These errors are called 
service errors because they are detected by a 
presentation services component within the 
LU. 


As a service component, PS.MC checks for cer- 
tain types of service errors. If « partner 
Te requests a function, such as handling of 
function management header (FMH) data, that 
is not supported by the local LU or trans- 
action program, PS.MC performs service error 
processing and advises the partner LU of the 
lack of support for that function. 


Another service error that PS.MC may detect 
is receipt of a map name from the partner LU 
that is not Known by the mapper. Similarly, 
the mapper may find that the data and the map 
name it has received frem the partner LU are 
incompatible, i.e., that the data cannot be 
mapped using the received map name. 


PS.MC also handles receipt of a service error 
notification from a partner LU when it is the 
partner that discovered the service error. 


The following sections describe the process- 
ing that PS.MC performs when it detects a 
service error, and the processing that 
results when PS.MC learns that the partner 
detected an error. 


SERVICE ERRORS DETECTED IN RECEIVED DATA 


As mentioned earlier, one type of error that 
PS.MC may detect is receipt of an invalid map 
name. Figure 5.2-7 on page 5.2-15 illus- 
trates this service error. In the figure, 
PS.MC has issued a RECEIVE_AND_WAIT to 
PS .CONV as a result of the 
MC_RECEIVE_AND_WAIT issued by the TP. The 
data returned in the RECEIVE_AND WAIT is a 
Map Name GDS variable. PS.MC stores the map 
name and issues another RECEIVE_AND_WAIT in 


order to receive the data that follows the 


map name. In this example, PS.MC receives a 
complete data GDS variable in the 
RECEIVE_AND_ WAIT (and therefore does not 
retrieve any more data from PS.CONV). 


PS.MC invokes the mapper, passing it the 
received map name and data. Instead of map- 
ping the data, however, the mapper returns to 
PS.MC a return code indicating that the map 
name received is invalid. The mapper has 


SNA Format and Protocol Reference Manual for LU Type 6.2 


TP PS .MC MAPPER PS.CONV 


MC_RECEIVE_AND_WAIT RECEIVE_AND_WAIT (FILL = LL) 


WHAT_RECEIVED = DATA_COMPLETE 


Data is a Map Name GDS variable. 
RECEIVE_AND_WAIT (FILL = LL) 


> 
WHAT_RECEIVED = DATA_COMPLETE 
ee ee ee 
Data is a complete data GDS variable. 
INPUT_DATA=data-1 
INPUT_MAP_NAME=map-name-1 
Pnan se RCAeh nko nce ee oRe umm Wer en Beene « 
RETURN_CODE=MAP_NOT_FOUND 
6S aa ee ele ee es Set, Ce es pe es 
SEND_ERROR (TYPE = SVC) 
> 
RETURN_CODE = OK 
Oy, ei is ace | eis eee ss <i, ie as, Sepa Gan Samael: Steg, end ia ne aie, as as nema fl aaa seas ea geal me 
SEND_DATA (DATA = Error Data GDS variable) 
> 
RETURN_CODE = OK 
case lc A ieee “sas! soem ine ire eek ns ids, iat Ste) sine: Sie nests Secs, Soe ele eee “pe as 
PREPARE_TO_RECEIVE (TYPE = FLUSH) 
> 
RETURN_CODE = OK 
Ne: Sete es me Re mye ee ge es ese Ree ve es ee a eee Oe 
RECEIVE_AND_WAIT 
> 
WHAT_RECEIVED = DATA_COMPLETE 
a onc, eae ac Saas a acces aig “Ny “yet es, “ee. laa <i: lly ts Se:- “ac. “na Mae ag ay Nae: Siea- Soems aea, hat “Ha Se. c0 


| See "Service Errors Detected in Received Data" for an explanation of the flows shown in this figure. 


Figure 5.2-9 on page 5.2-18 is the complement of this figure, showing the processing that occurs 
when an LU is informed of an error committed at that LU. Note: Only those parameters pertinent to | 
the example are shown. | 


Figure 5.2-7. Detecting a Service Error as a Result of MC_RECEIVE_AND_WAIT Processing 


detected a service error and informed PS.MC with TYPE(SVC). This tells the partner LU 
of the error. only that an error occurred; it does not 

indicate to the partner the exact nature of 
PS.MC now has to inform the partner that a the error. In order to convey this important 
service error occurred and to return SEND information to the partner, PS.MC creates an 
control of the mapped conversation to the Error Data GDS variable. The GDS variable 
partner TP. PS.MC first issues SEND_ERROR carries an indication that the received map 
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PS.VERB_ROUTER 


PS .MC PS .CONV 
Call MC_TEST_PROC | TEST 
RETURN_CODE = OK 
an: “dels, ‘tla ese fac ess ee = Sv” Sas aes eae ea ate See ie eae fe oe 
RECEIVE_AND_WAIT (FILL = LL) 
> 
WHAT_RECEIVED = DATA_COMPLETE 
i= ecb Tele Tew Se -ste cameas. hadi, ale ae. aaa <a Nee) Cesc ae ds ae 
PS.MC examines the data 
and detects an error. 
SEND_ERROR (TYPE = SVC) | 
> 


SEND_DATA (DATA = Error Data GDS variable) — 


RETURN_CODE = UNSUCCESSFUL 


RETURN_CODE = OK 


> 
RETURN_CODE = OK 
PREPARE_TO_RECEIVE (TYPE = FLUSH) : 
RETURN_CODE = OK 
POST_ON_RECEIPT (FILL = LL) 


See "Service Errors Detected in Received Data" for an explanation of the flows shown in this figure. 


| Note: 


Figure 


Only those parameters pertinent to the example are shown. 


5.2-8. Detecting a Service Error as a Result of a Call to MC_TEST_PROC 


name was not found in the wapper's library of 
map names; the invalid map name is also 
returns. to the partner LU in the Error Data 


SS2 vartable so that the partner LU will Know 
PS.MC 


exactly which map name was unknown. 
then issues a SEND_DATA carrying the Error 
Data GDS variable to PS.CONV. 


PS.MC completes its processing of the 
received service error by issuing  PRE- 
PARE_TOLRECEIVE with TYPE(FLUSH), which 


returns SEND control of the mapped conversa- 
tion to the partner TP. 


PS.MC does not 
service error committed by the partner LU. 
It instead returns SEND control of the mapped 
conversation to the partner TP, which is 
informed of the error, and waits for the 
partner TP to recover from the error. The 
transaction program that committed the error 


detected. 
“jn data that was received as a result of a 
call to MC_TEST_PROC by the PS.VERB_ROUTER 
while it is processing a WAIT verb. 


inform its local TP of the 


IME , Y 


is responsible for determining what error 
recovery is to take place. When: the service 
error is detected as a result of an 
MC_RECEIVE_AND_WAIT, PS.MC immediately issues 
another RECEIVE_AND_WAIT to wait for informa- 
tion from the partner. 


Figure 5.2-8 illustrates a slightly different 
situation in which a service error is 
This time, the error is detected 


Another 
difference is that instead of the mapper 
detecting the error, PS.MC discovers it. One 


cause of this type of error would be incoming 


data requesting a function that the receiving 
PS.MC did not support (for example, the func- 
tion of handling FM header data when User 
Control Data GDS variables are not supported 
by the receiving PS.MC). 
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In handling this error during a call to 
MC_TEST_PROC, PS.MC, as in the 
MC_RECEIVE_AND_WAIT example, issues 
SEND_ERROR, followed by SEND_DATA with an 
Error Data GDS variable, followed by PRE- 
PARE_TO_RECEIVE with TYPE(FLUSH). PS.MC then 
continues, however, in a manner different 
from the MC_RECEIVE_AND_WAIT example: 
MC_TEST_PROC returns to the PS.VERB_ROUTER, 
after passing SEND control of the mapped con- 
versation to the partner (and after causing 
posting to be re-activated). The 
PS.VERB_ROUTER ts informed that its MC_TEST 
was unsuccessful, but not of the specific 
error. 


PROCESSING OF A SERVICE ERROR DETECTED BY 
PARTNER LU 


PS.MC also handles service errors that are 
detected by the partner LU. The error could 
have been detected in data sent to the part- 
ner LU by the local TP. Alternatively, the 
partner LU may have detected an error while 
sending data to PS.MC. Figure 5.2-9 on page 
5.2-18 and Figure 5.2-10 on page 5.2-19 
illustrate these two cases of error notifica- 
tion. 


In Figure 5.2-9 on page 5.2-18, the trans- 
action program is in the midst of sending 
data to the partner transaction = program. 
However, a return code of SVC_ERROR_PURGING 
is returned on one of the SEND_DATAs that 
PS .MC issues to PS .CONV. The 
SVC_ERROR_PURGING return code indicates that 
the partner LU has detected an error in the 
data it has received. PS.MC, upon receipt of 
the SVC_ERROR_PURGING return code, issues a 
RECEIVE_AND_WAIT to learn the type of service 
error the partner LU encountered. The data 
returned in the RECEIVE_AND_WAIT consists of 
an Error Data GDS variable specifying the 
type of service error. The return code that 
PS.MC returns to the transaction program is 
derived from the information carried in the 
Error Data GDS variable. Before returning to 
the transaction program, PS.MC issues another 
RECEIVE_AND_WAIT to retrieve the SEND indica- 
tor. As discussed in the previous section, 
the transaction program that caused a service 
error to be committed is responsible for 
determining what error recovery is to occur. 
PS.MC returns to the transaction program with 


a return code, in this example, of 
MAP_NOT_FOUND. The transaction program still 
has SEND control of the mapped conversation 
(the transaction program is placed in SEND 
state as ae result of a remotely detected 
error, even if the transaction program was In 
RECEIVE state when it issued the verb on 
which the error is reported). 


The example shown in Figure 5.2-7 on page 
5.2-15 and described in "Processing of a 
Service Error Detected by Partner LU" is the 
complement of the example just discussed and 
shown in Figure 5.2-9 on page 5.2-18. The 
first figure mentioned shows a transaction 
program requesting to receive data on a 
mapped conversation and the LU detecting an 
error in the data received. The second fig- 
ure shows a transaction program sending data 
on a mapped conversation and being notified 
that a problem with the data was encountered 
at the partner LU. 


As was pointed out in "Block Mapping" on page 
5.2-8, PS.MC never sends a service-error 
notification to its partner from SEND state. 
An LU providing implementation-defined map- 
ping, however, could issue such an error. 
For example, the LU may have mapped some, but 
not all, of the data issued by the trans- 
action program in an MC_SEND_DATA. The part 
of the data that has been mapped is sent on 
the mapped conversation. While mapping the 
remainder of the data, however, the mapper 
discovers a problem. It informs its PS.MC 
component, which then issues a service-error 
notification indicating that data truncation 
has occurred at the sending LU. An LU with 
implementation-defined mapping may also, at 
some point, need to notify its partner that 
an error was detected but no data truncation 
has occurred. 


While PS.MC does not issue service errors 
from SEND state, it does handle receipt of 
notifications that the partner LU detected a 
service error while it was in SEND state. 
Figure 5.2-10 on page 5.2-19 illustrates the 
processing that PS.MC performs as a result of 
this error. If it has received any incom- 
plete data prior to receiving the 
service-error notification, PS.MC purges the 
data and immediately begins to wait for new 
data to arrive. Again, the transaction pro- 
gram is not informed of the error. 
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TP ; PS .MC | PS.CONV 


MC_SEND_DATA SEND_DATA 
id a > 
RETURN_CODE = OK RETURN_CODE = OK 
Mes aes Sa ae iin aes vee 1 aes a a Sa ee ee a eh as ae ee eal as sae sts Nees iil iden iain ata pata ea nS! enue! i aleaastn tga Sala ia 
® 
e 
be nk 3 
MC_SEND_DATA SEND_DATA 
> > 


RETURN_CODE = SVC_ERROR_PURGING 


Oe 
- RECEIVE_AND_WAIT 
> 
WHAT_ RECEIVED =. DATA_ COMPLETE 
ica inka aes “eas Sel Caled Teeth eats gia a Saas He, cas faced awa? ae ms, Jags, <a’ Geis» Sear” ha 
Data is an Error Data GDS variable. 

RECEIVE_AND_WAIT | 

> 
RETURN_CODE = MAP_NOT_FOUND : WHAT_RECEIVED = SEND » 
Oa a ee ee en ee es Se acl aca: a a Ae ga isc tsa at. Gy cag Ya: Aaa sls as aml 


See "Processing of a Service Error Detected by Partner LU" for an explanation of the flows that are 
shown in this figure. 


Figure 5.2-7 on page 5.2-15 is the complement of this figure, showing the processing that occurs at 
the LU that detects an error in received data. The SVC_ERROR_PURGING return code can be returned on 
several verbs. SEND_DATA is used here as an example of one of the verbs possible. 


Note: Only those parameters pertinent to the example are shown. 


| Figure 5.2-9. Receipt by PS.MC of a SVC_ERROR_PURGING Return Code 
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PS .CONV 


MC_RECEIVE_AND_WAIT RECEIVE_AND_WAIT (FILL = LL) 
> 


RETURN_CODE = SVC_ERROR_TRUNC/SVC_ERROR_NO_TRUNC 


PS.MC purges any data that it has received 
prior to the service error notification. 


RECEIVE_AND_WAIT 


See "Processing of a Service Error Detected by Partner LU" for an explanation of the flows that are 
shown in this figure. 


The processing that occurs when a SVC_ERROR_TRUNC or SVC_ERROR_NO_TRUNC return code is received by 
PS.MC while processing a call to MC_TEST_PROC differs from this figure only in that PS.MC does not 
issue a RECEIVE_AND_WAIT after receiving the return code. PS.MC returns a code of UNSUCCESSFUL to 
the PS.VERB_ROUTER. 


Note: Only those parameters pertinent to the example are shown. 


Figure 5.2-10. Receipt by PS.MC of a SVC_ERROR_TRUNC or SVC_ERROR_NO_TRUNC Return Code 


PS MC 


FUNCTION: This procedure receives mapped conversation verbs issued by the transaction 
program, and routes each verb to the appropriate procedure for processing. 


PS.MC is called by PS.VERB_ROUTER (Chapter 5.0) as a result of the transaction 
program's issuing a mapped conversation verb. 


INPUT: The current transaction prog.am verb is passed with parameters; 
PS_PROCESS_DATA is provided by the resources manager at creation time and may 
be accessed by all the procedures within PS. 


OUTPUT: Refer to the procedures that are called from this procedure for the specific 
outputs. 


Referenced procedures, FSMs, and data structures: 


MC_ALLOCATE_PROC page 5.2-20 
MC_CONF IRM_PROC page 5.2-21 
MC_CONFIRMED_ PROC page 5.2-22 
MC_DEALLOCATE_PROC page 5.2-23 
MC_FLUSH_PROC page 5.2-23 
MC_GET_ATTRIBUTES_ PROC page 5.2-24 
MC_POST_ON_RECEIPT_PROC page 5.2-25 
MC_PREPARE_TO_RECEIVE_PROC page 5.2-26 
MC_RECEIVE_AND_WAIT_PROC page 5.2-27 
MC_REQUEST_TO_SEND_PROC page 5.2-37 
MC_SEND_DATA_PROC page 5.2-38 
MC_SEND_ERROR_PROC page 5.2-40 
MC_TEST_PROC page 5.2-28 
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PS _MC 


5.2-20 


Select based 


on the mapped conversation verb. Cissued by the TP): 


When MC_ALLOCATE 
Call MC_ALLOCATE_PROC (page 5.2-20). 
When MC_CONFIRM 
Call MC_CONFIRM_PROC (page 5.2-21). 
When MC_CONFTeNeD 
Call mC_CONFIRMED_PROC (page 5.2-22). 
wnen MC_DEALLOCATE | 
Call MC_DEALLOCATE_PROC (page 5.2-23). 
When MC_FLUSH 
CALL MC_FLUSH_ PROC (page 5.2-23). 
When MC_ GET_ ATTRIBUTES 
Call MC_GET_ATTRIBUTES_PROC (page 5.2-24). 
When MC_ POST_ ON_RECEIPT 
Call MC_POST_ON_RECEIPT_PROC (page 5.2-25). 
When MC_PREPARE_TO_RECEIVE | 
Call MC_ PREPARE _TO_RECEIVE PROC (page 5.2- 26). 
When MC_ RECEIVE_ AND WAIT 
Call MC _RECEIVE _AND_ WAIT_PROC Conde 5.2-27). 
When MC_REQUEST_TO_SEND 
Call MC_REQUEST_TO_SEND_PROC (page 5.2-37). 
When MC_SEND_DATA 
Call MC_SEND_DATA_PROC (page 5.2-38). 
When MC_ SEND_ ERROR 
Call MC_ SEND_ ERROR_PROC (page 5.2-40). 
When MC _TEST 
Call MC_TEST_PROC (page 5.2-28). 


MC_ALLOCATE_PROC 


- FUNCTION: 


— INPUT: 


OUTPUT: 


NOTES: 1. 


2% 


This procedure handles the allocation of mapped conversations. 


MC_ALLOCATE verb parameters (See SNA Transaction Programmer's Reference Manual 


for LU Type 6.2.) 


A return code as described in SNA Transaction Programmer's Reference Manual 


for LU Type 6.2. Also, if the allocation is successful, PS.MC initializes the 


mapped conversation fields in the RCB that is created by the ALLOCATE verb and 
returns the ID of this RCB. 


The SNASVCMG mode name is not allowed at ‘the mapped conversation protocol 
boundary. 


A return code on ALLOCATE of PARAMETER_ERROR or UNSUCCESSFUL indicates that no 
resource has been allocated (and, therefore, no RCB has been created). When 
the ALLOCATE returns a RETURN_CODE value of OK or ALLOCATION_ ERROR, an RCB has 
been created. 


Referenced procedures, FSMs, and data structures: 


PS VERB ROUTER page 5.0-11 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
RCB | page A-7 
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MC_ALLOCATE_PROC 


If the transaction program supports mapped conversations and 
the mode name is not SNASVCMG (see Note 1) then 
Call PS_VERB_ROUTER (Chapter 5.0) to issue an ALLOCATE 
verb using the parameters given with the MC_ALLOCATE verb and 
specifying that the conversation type is mapped. 

Set the return code to the value returned by the ALLOCATE verb. 

If the return code from ALLOCATE was OK or ALLOCATION_ERROR then 
Prepare to return the ID of the RCB created by the ALLOCATE verb. 
Initialize RCB.MAPPER_SAVE_AREA as required by the implementation. 
Set RCB.MC_MAX_SEND_SIZE to the implementation limit on the 

length of RUs that can be sent to the partner LU. 


Else (allocation of a conversation is not allowed) 
Call DEALLOCATION_CLEANUP_PROC (Chapter 5.0). 


MC_CONF IRM_PROC 


FUNCTION: 


INPUT: 


OUTPUT: 


NOTES: 1. 


This proceaure processes MC_CONFIRM verbs. 


MC_CONFIRM verb parameters (See SNA Transaction Programmer's Reference Manual 
for LU Type 6.2.) 


A return code as described in SNA Transaction Programmer's Reference Manual 
for LU Type 6.2. If a request to send is received from the remote transaction 
program while processing a CONFIRM verb, this request is also indicated to the 
local TP. 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_CONFIRM verb. A_ state check is performed by PS.CONV 
(Chapter 5.1) during its processing of the CONFIRM verb. 


The processing that PS.MC performs as a result of receiving a return code of 
SVC_ERROR_PURGING involves issuing the necessary RECEIVE_AND_WAIT verbs. A 
request to send by the remote TP may be indicated by one of these 
RECEIVE_AND_WAIT verbs, as well as by the CONFIRM verb. In either case, the 
indication 1s passed to the local TP. 


Referenced procedures, FSMs, and data structures: 


RCVD_SVC_ERROR_PURGING page 5.2-42 
PS_ SPS page 5.3-35 
UPM_MAPPER page 5.2-46 
PS_VERB_ROUTER page 5.0-11 
RCB page A-7 
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MC_CONFIRM_PROC 


Find the RCB for the specified conversation (resource). 
Call PS_VERB_ROUTER (Chapter 5.0) to issue a CONFIRM verb 
for the current conversation. 


Select based on the code returned by CONFIRM: 
— When OK 
Set the return code to the value returned by the CONFIRM verb. 
Call UPM_MAPPER (page 5.2-46) to record a positive confirmation. 
When PROG_ERROR_PURGING 
Set the return code to the value returned by the CONFIRM verb. 
Call UPM_MAPPER (page 5.2-46) to record a remotely detected 
error of the type indicated by the return code from CONFIRM. 
When ALLOCATION_ERROR, RESOURCE_FAILURE_RETRY, or RESOURCE_FAILURE_NO_RETRY 
Set the return code to the value returned by CONFIRM. 
When DEALLOCATE_ABEND_PROG 
Set the return code to DEALLOCATE_ABEND. 
When DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER 
Set the return code to RESOURCE_FAILURE_NO_RETRY. 
When BACKED_OUT 
Call PS_SPS (syne point manager, Chapter 5.3). 
Set the return code to the value returned by CONFIRM. 
When SVC_ERROR_PURGING 
Call RCVD_SVC_ERROR_PURGING (page 5.2-42) to 
get and process error data from the remote TP. 
Set the return code to the value returned by RCVD_SVC_ERROR_PURGING. 
If a request to send has been received from the remote TP and not 
indicated on a prior MC_CONFIRM, MC_RECEIVE_AND WAIT, MC_SEND_DATA, or 
MC_SEND_ERROR verb then 
Return a request to send received indication to the local TP. 


MC_CONF IRMED_PROC 


FUNCTION: This procedure processes MC_CONFIRMED verbs. 


INPUT: MC_CONFIRMED verb parameters (See SNA Transaction Programmer's Reference Manu- 
al for LU Iype 6.2.) 


NOTE: PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_CONFIRMED. A state check is performed by PS.CONV 
(Chapter 5.1) during its processing of the CONFIRMED verb. 


Referenced procedures, FSMs, and data structures: 
PS VERB ROUTER page 5.0-11 


Call PS_VERB_ROUTER (Chapter 5.0) to issue a CONFIRMED 
verb for the current conversation. 
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MC_DEALLOCATE_PROC 
MC_DEALLOCATE_PROC 


This procedure handles the deallocation of mapped conversation resources. 


MC_DEALLOCATE verb parameters (See SNA Transaction Programmer's Reference Man- 
val for LU Type 6.2.) 


A return code as described in SNA Transaction Programmer's Reference Manual 
for LU Type 6.2. 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_DEALLOCATE. A state check is performed by PS.CONV 
(Chapter 5.1) during its processing of the DEALLOCATE verb. 


Referenced procedures, FSMs, and data structures: 


RCVD_SVC_ERROR_PURGING page 5.2-42 
PS_VERB_ROUTER page 5.0-11 
UPM_MAPPER page 5.2-46 
RCB page A~-7 


Find the RCB for the specified conversation (resource). 
If the deallocation type is ABEND then 
Clear RCB.MC_RECEIVE_BUFFER. 
Call PS_VERB_ROUTER (Chapter 5.0) to issue a DEALLOCATE 
verb for the current conversation with no error data and indicating 
that the type of deallocation is ABEND_PROG. 
Else 
Call PS_VERB_ROUTER (Chapter 5.0) to issue a DEALLOCATE 
verb for the current conversation with no error data and the 
specified deallocation type. 


Select based on the return code from DEALLOCATE: 
When OK, ALLOCATION_ERROR, RESOURCE _FAILURE_RETRY, or RESOURCE _FAILURE_NO_RETRY 
Set the return code to the code returned by DEALLOCATE. 
When PROG_ERROR_PURGING 
Set the return code to the code returned by DEALLOCATE. 
Call UPM_MAPPER (page 5.2-46) to record a 
remotely detected error of the type indicated by the return code 
from the DEALLOCATE verb. 
When DEALLOCATE_ABEND_PROG 
Set the return code to DEALLOCATE_ABEND. 
When DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER 
Set the return code to RESOURCE_FAILURE_NO_RETRY. 
When SVC_ERROR_PURGING 
Call RCVD_SVC_ERROR_PURGING (page 5.2-42). 


MC_FLUSH_PROC 


This procedure processes MC_FLUSH verbs. 


MC_FLUSH verb parameters (See SNA Transaction Programmer's Reference Manual 
for LU Type 6.2.) 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_LFLUSH. A state check 1s performed by PS.CONV (Chapter 
5.1) during its processing of the FLUSH verb. 


Referenced procedures, FSMs, and data structures: 
PS_VERB_ROUTER page 5.0-11 


Call PS_VERB_ROUTER (Chapter 5.0) to issue a FLUSH 
verb for the current conversation. 
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MC_GET_ATTRIBUTES_PROC 


FUNCTION: This procedure handles requests from the transaction program for information 
: about a mapped conversation. 


INPUT: MC_GET_ATTRIBUTES verb parameters (See SNA Transaction Programmer's Reference 
Manual for LU Type 6.2.) 


OUTPUT: PS.MC issues a GET_ATTRIBUTES (See SNA Transaction Programmer's Reference Man- 
ual for LU Type 6.2) verb for the resource specified in MC_GET_ATTRIBUTES. 
PS.MC places the information returned in the GET_ATTRIBUTES verb into the 
appropriate fields in the MC_GET_ATTRIBUTES and returns control to the trans- 
action program. 


Issue a basic GET_ATTRIBUTES verb on the current conversation. 


Return the attributes of the mapped conversation, returned 
from the GET_ATTRIBUTES verb, to the TP, such as the fully 
qualified LU names of both LUs of the conversation, the 
mode name, synchronization level, security profile, and 
security user ID. 
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MC_POST_ON_RECEIPT_PROC 
MC_POST_ON_RECEIPT_PROC 


FUNCTION: This procedure processes MC_POST_ON_RECEIPT verbs. 


INPUT: MC_POST_ON_RECEIPT verb parameters (See SNA Transaction Programmer's Reference 
Manual for LU Type 6.2.) 

OUTPUT: If the MC_RECEIVE_BUFFER is empty when the MC_POST_ON_RECEIPT is issued, PS.MC 
issues a POST_ON_RECEIPT verb Otherwise, no POST_ON_RECEIPT is necessary (see 
below). 


NOTES: 1. If the MC_RECEIVE_BUFFER is not empty, the transaction program has,» prior to 
issuing the current MC_POST_ON_RECEIPT, issued one or more MC_POST_ON_RECEIPTs 
followed by one or more MC_TESTs. The MC_TEST processing caused PS.MC to 
receive data (via a RECEIVE_AND_WAIT) from PS.CONV (Chapter 5.1) and PS.MC has 
stored that data in the MC_RECEIVE BUFFER. See '"'MC_TEST_PROC" on page 5.2-11 
for a discussion of MC_TEST. 


2. If the information stored in the MC_RECEIVE_BUFFER indicates that a complete 
Application Data or User Control Data GDS variable has been received (and that 
the data in that variable has been mapped), then PS.MC has’ already informed 
the transaction program via the RETURN_CODE on a previous MC_TEST that posting 
has been satisfied. The transaction program, however, has issued another 
MC_POST_ON_RECEIPT (after having issued an MC_TEST on which was) returned a 
return code of OK--DATA). PS.MC remembers the fact that an MC_POST_ON_RECEIPT 
has been issued, in case the transaction program issues another MC_TEST, but 
does not issue a POST_ON_RECEIPT to PS.CONV. 


3. If the data stored in the MC_RECEIVE_BUFFER is not complete (i.e.; a Map Name 
GDS variable, but no data, has been received; or part, but not all, of the 
data in an Application or FMH Data GDS variable has been received), posting is 
still activated. PS.MC, therefore, does not issue a POST_ON_RECEIPT to 
PS.CONV. In this situation, the transaction program has issued one or more 
prior MC_TESTs, all of which have been unsuccessful. 


4. PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_POST_ON_RECEIPT. This state check is performed by 
PS.CONV (Chapter 5.1) during its processing of the POST_ON_RECEIPT verb, if 
PS.MC issues one. As described above, there are certain situations in which 
PS.MC receives an MC_POST_ON_RECEIPT from the transaction program but does not 
issue a POST_ON_RECEIPT to PS.CONV. In these situations, however, the 
MC_RECEIVE_BUFFER in the RCB is not empty. This indicates that the conversa- 
tion is in RECEIVE state and therefore the MC_POST_ON_RECEIPT is valid at the 
present time. 


Referenced procedures, FSMs» and data structures: 
RCB page A-7 


If the RCB.MC_RECEIVE_BUFFER for the current conversation is empty then 
Issue a basic POST_ON_RECEIPT verb on this conversation, specifying the maximum 
length of the data to be received before posting, and that posting should 
be done after receiving a complete logical record. 
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MC_PREPARE_TO_RECEIVE_PROC 


FUNCTION: This procedure processes MC_PREPARE_TO_RECEIVE verbs. 


PS.MC issues a PREPARE_TO_RECEIVE verb against the resource specified in the 
MC_PREPARE_TO_RECEIVE. It sets the return code field in the 
MC_PREPARE_TO_RECEIVE based upon the value returned in the PREPARE_TO_RECEIVE. 
Some return codes, such as OK, are placed in the MC_PREPARE_TO_RECEIVE 
unchanged. Others, such as DEALLOCATE_ABEND_ PROG, are transformed to another 
value before being placed in the MC_PREPARE_TO_RECEIVE. In addition, some 
return codes cause PS.MC to perform further processing. For example, when 
PS.MC receives a return code of PROG_ERROR_PURGING to its PREPARE_TO_RECEIVE, 
it invokes the mapper to inform that procedure that an error was detected by 
the partner transaction program. (See "Mapper Invocation" on page 5.2-9.) 
When a return code of SVC_ERROR_PURGING is received, PS.MC performs the proc- 
essing necessary to determine what type of service error the PS.MC component 
at the partner LU encountered. A return code reflecting the type of error is 
returned to the local transaction program in the MC_PREPARE_TO_RECEIVE. (See 
"Processing of a Service Error Detected by Partner LU" on page 5.2-17.) 


INPUT: MC_PREPARE_TO_RECEIVE verb parameters (See SNA Transaction Programmer's Refer- 
ence Manual for LU Type 6.2.) 


OUTPUT: PS.MC issues a PREPARE_TO_RECEIVE verb and sets the return code field in the 
MNC_PREPARE_TO_RECEIVE based upon the corresponding field in the PRE- 
PARE_TO RECEIVE. 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_PREPARE_TO_RECEIVE. This state check is performed by 
PS.CONV (Chapter 5.1) during its processing of the PREPARE_TO_RECEIVE verb. 


Referenced procedures, FSMs, and data structures: 


UPM_MAPPER page 5.2-46 
RCVD_SVC_ERROR_ PURGING page 5.2-42 
PS_VERB_ROUTER page 5.0-11 
RCB | page A-7 


Find the RCB for the current conversation. 
Call the PS_VERB_ROUTER (Chapter 5.0) to issue a 
PREPARE_TO_RECEIVE verb, specifying a LOCKS value and verb type; 
for the current RCB. 
Select based on the returned PREPARE_TO_RECEIVE return code: 
When (OK, ALLOCATION_ERROR, RESOURCE_FAILURE_RETRY, RESOURCE_FAILURE_NO_RETRY ) 
Set the MC_PREPARE_TO_RECEIVE return code to the PREPARE_TO_RECEIVE return code. 
When (PROG_ERROR_PURGING ) 
Call the UPM_MAPPER (page 5.2-46) to record 
the return code for the remotely detected error. 
When (DEALLOCATE_ABEND_PROG) 
Set the MC_PREPARE_TO_RECEIVE return code to DEALLOCATE_ABEND. 
When (DEALLOCATE_ABEND_SVC, DEALLOCATE_ABEND_TIMER) 
Set the MC_PREPARE_TO_RECEIVE return code to RESOURCE_FAILURE_NO_RETRY. 
When (SVC_ERROR_PURGING) 
Call RCVD_SVC_ERROR_PURGING (page 5.2-42) to 
do service error processing, specifying the return code and current RCB. 
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MC_RECEIVE_AND_WAIT_PROC 
MC_RECEIVE_AND_WAIT_PROC 


FUNCTION: This procedure processes MC_RECEIVE_AND_WAIT verbs. 


PS.MC first determines the status of the MC_RECEIVE_BUFFER. Processing of the 
MC_RECEIVE_AND_WAIT continues based upon the status of the buffer. 


The MC_RECEIVE_BUFFER contains any information that has been received from 
PS.CONV (Chapter 5.1) but has not yet been passed to the transaction program. 
It is in one of the following states: (1) the buffer is empty, (2) the buffer 
contains information, but the information is incomplete and more has’ to be 
received before it can be passed to the transaction program, or (3) the buffer 
contains information that 1s complete and ready to be passed to the trans- 
action program. 


If the MC_RECEIVE_BUFFER is not empty, the transaction program has issued one 
or more prior MC_TEST verbs. The processing that PS.MC performed as a result 
of the MC_TEST(s) involved receiving data from PS.CONV. It is the data that 
resulted from the MC_TEST(s) that is stored in the MC_RECEIVE_BUFFER. 


INPUT: MC_RECEIVE_AND_WAIT verb parameters (See SNA Transaction Programmer's Refer- 
ence Manual for LU Type 6.2.) 


OUTPUT: Fields in the MC_RECEIVE_AND_WAIT are set based upon the type of information 
being returned to the transaction program. 


If the MC_RECEIVE_BUFFER is empty or contains incomplete data, this procedure 
causes one or more RECEIVE_AND_WAIT verbs to be issued to PS.CONV. PS.MC con- 
tinues to issue RECEIVE_AND_WAITs until it has a complete piece of informa- 
tion. 


NOTES: 1. PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_RECEIVE_AND_WAIT. This state check is. performed by 
PS.CONV (Chapter 5.1) during its processing of the RECEIVE_AND_WAIT verb, if 
PS.MC issues one. If the MC_RECEIVE_BUFFER already contains complete informa- 
tion ready to be passed to the transaction program, PS.MC does not issue a 
RECEIVE_AND_WAIT. However, the fact that the MC_RECEIVE_ BUFFER is not empty 
indicates that the mapped conversation is in RECEIVE state and that the 
MC_RECEIVE_AND_WAIT is valid at the present time. 


2. RECEIVE_INFO_PROC ( page 5.2-30 ) issues a RECEIVE_AND_WAIT to PS.CONV and 
causes processing of the information returned in the RECEIVE_AND_WAIT to 
occur. It is possible that when control is returned from this procedure, the 
MC_RECEIVE_ BUFFER is empty, even though data was returned in the 
RECEIVE_AND_WAIT. This 1s the case when PS.MC detects an error in the data 
(e.g., the data specified a function not supported). Nothing is placed in the 
buffer during this invocation of RECEIVE_INFO_PROC. For more details, see 
“Service Errors Detected in Received Data" on page 5.2-14. 


Referenced procedures, FSMs, and data structures: 
RECEIVE_INFO_PROC page 5.2-30 


RCB page A-7 


If the RCB.MC_RECEIVE_ BUFFER contains a null entry, map name, data-continued 
indicator, or map name and data-continued indicator then 
Call RECEIVE_INFO_PROC(RCB) (page 5.2-30) 
to issue a RECEIVE_AND_WAIT verb. 
If the RCB.MC_RECEIVE_BUFFER does not contain a null entry, or contains 
mapped data or a return code entry then 
Select based on the contents of the RCB.MC_RECEIVE_BUFFER: 
When the buffer element contains a WHAT_RECEIVED indicator 
Put the WHAT_LRECEIVED indicator in the MC_RECEIVE_AND_WAIT verb. 
Set the MC_RECEIVE_AND_WAIT return code to OK. 
When the buffer element contains a return code 
Set the MC_RECEIVE_AND_WAIT return code to the buffer return code. 
When the buffer element contains mapped data 
Retrieve the mapped data from the MC_RECEIVE_BUFFER and place the 
amount of data requested by the transaction program into the DATA 
field of the MC_RECEIVE_AND_WAIT. Indicate whether data was complete 
or truncated, and indicate that FMH data, if present, was complete. 
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5.2-28 


Clear the MC_ 


If a request 


RECEIVE_BUFFER for the current RCB. | ; as 
to send has been received from the remote TP aad not returned on 


a prior MC_CONFIRM, MC_RECEIVE_AND_WAIT, MC_SEND_DATA, or MC_SEND_ERROR verb then 
Return a request-to-send-received indication to the local TP on the verb. 


MC_TEST_PROC 


wor 9. 


FUNCTION: 
INPUT: 


OUTPUT: 


NOTES: 1. 


This procedure processes MC_TEST verbs. 
MC_TEST 


PS.MC sets the RETURN_CODE field in the MC_TEST based upon the outcome of the 
specified test. Depending upon the type of test specified and the information 
contained in the RCB, PS.MC may issue basic conversation verbs that are proc- 
essed by PS.CONV. RCB.MC_RECEIVE_BUFFER, or a return code obtained by calling 
TEST_PROC (page 5.1-27). 


If RCB.MC_RECEIVE_BUFFER is not empty when a return code of OK--NOT_DATA is 
received, the partner LU has committed a protocol violation. For example, the 
partner LU has sent data with an indication that the data is continued in the 
next logical record, but instead of ened the remaining data, the partner LU 
allowed a SEND Enencetes to flow. 


RCB.MC_RECEIVE_ BUFFER may be enpty at this point: This occurs when the TEST 
verb just issued returns OK--DATA but an error is detected in the data by 
RECEIVE_INFO_PROC (page 5.2-30). For more details, see "Service Errors 
Detected in Received Data" on page 5. 2- 14. | 


An INDICATOR element cannot appear in RCB. MC_ RECEIVE_BUFFER here. If the TEST 
verb just issued returns OK--NOT_DATA; the conversation indicator that caused 
this return code remains in = PS.CONV's buffer. ©PS.MC does not issue a 
RECEIVE_AND_WAIT to PS.CONV to get the indicator until the transaction program 
issues an MC_RECEIVE_AND_WAIT. 


The RCB.MC_RECEIVE_BUFFER contains data ready to be returned to the trans- 
action program as ae result of one or more prior calls to MC_TEST 
(TEST=POSTED). 


Referenced procedures, FSMs, and data structures: 


TEST_PROC page 


| 5.1-27 
RECEIVE_INFO_PROC i : page 5.2-30 
PROTOCOL_ERROR_PROC | | | ai page 5.2-47 
PROCESS _ERROR_OR_FAILURE_RC Ho | page 5.2-31 
PS_VERB_ROUTER page 5.0-11 
RCB page A-7 
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Select based on the specified type of test: 
When POSTED 
If RCB.MC_RECEIVE_BUFFER is empty 
or contains a map name or unmapped data then 
Call TEST_PROC (page 5.1-27) to determine whether the current 
conversation has been posted indicating that data, status, or a 
request for confirmation has been received from the remote TP. 
Select based on the return code from TEST_PROC: 
When OK--DATA 
- Call RECEIVE_INFO_PROC (page 5.2-30) to receive 
the data and place it in RCB.MC_RECEIVE BUFFER. 
When OK--NOT_DATA 
If RCB.MC_RECEIVE_BUFFER is empty then 
Put the return code from TEST_PROC in RCB.MC_RECEIVE_ BUFFER. 
Else (optional check when receiving datas see Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Replace the contents of RCB.MC_RECEIVE BUFFER mith the 
return code RESOURCE_FAILURE_NO_RETRY. 
When POSTING _NOT_ACTIVE or UNSUCCESSFUL 
Put the return code from TEST_PROC in RCB.MC_RECEIVE_ BUFFER. 
Otherwise 
Call PROCESS_ERROR_OR_FAILURE_RC (page 5.2-31) 
to process the return code frow TEST_PROC. 
If RCB.MC_RECEIVE BUFFER is empty or contains a map name or 
unmapped data (see Note 2) then 
Set the code to be returned by this routine to UNSUCCESSFUL. 
Call PS_VERB_ROUTER (Chapter 5.0) to issue a POST_ON_RECEIPT 
verb specifying posting when a complete or truncated logical 
record is received. 
Else 
Select based on the type of information in RCB.MC_RECEIVED_BUFFER 
(see Note 3): 
When it is mapped data 
Set code returned by this routine to OK--DATA. 
When it is a return code 
Set the code returned by this routine to the return 
code found in RCB.MC_RECEIVE_BUFFER. 
Clear RCB.MC_RECEIVE_BUFFER. 
Else 
If there is mapped data in RCB.MC_RECEIVE_ BUFFER and the local 
TP has issued a MC_POST_ON_RECEIPT verb since this data was 
mapped then (see Note 4) 
Set the code to be returned by this routine to OK--DATA. 
Else 
Set the code to be returned to POSTING _NOT_ACTIVE. 


When REQUEST_TO_SEND_RECEIVED 
If a request to send has been received from the remote TP and not 
yet returned to the local TP then 
Return a request-to-send-received indication to the local TP. 
Else 
Call TEST_PROC (page 5.1-27) to determine whether 
a request to send has been received from the remote TP and is 
being held by PS.CONV. | 
If a request to send was held by PS.CONV then 
Return a request-to~-send-received indication to the local TP. 
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RECEIVE_INFO_PROC 


FUNCTION: The purpose of this procedure is to receive information from PS.CONV hapten 
5.1) and to place that information in the MC_) RECEIVE _BUFFER. 


This procedure issues a RECEIVE_AND_WAIT for the mapped conversation corre- 
sponding to the passed RCB. PS.MC continues the processing of the 


RECEIVE_AND_WAIT in other procedures, depending upon the return code carried 
in the RECEIVE_AND_WAIT. | 


INPUT: The RCB corresponding to the mapped conversation specified in the TRANS- 
ACTION_PGM_VERB currently being processed 


OUTPUT: See the procedures called for the specific outputs. 


Referenced procedures, FSMs, and data structures: 


PROCESS_ERROR_OR_FAILURE_RC page 5.2-31 
PROTOCOL_ERROR_PROC page 5.2-47 
PROCESS DATA_COMPLETE page 5.2-33 
PROCESS_DATA_INCOMPLETE page 5.2-36 
UPM_MAPPER page 5.2-46 
RCB page A-7 


Issue a basic RECEIVE_AND_WAIT verb for a complete logical record 
specifying the maximum length of the data. 
If a request to send data was received from the remote TP then 
Save an indication of the request to be returned later. 
If the RECEIVE_AND_WAIT was successful then 
Select based on the WHAT_RECEIVED field on tne RECEIVE_AND_WAIT verb: 
When the data received is complure 
Call PROCESS _DATA_COMPLETE(RCB+ RECEIVE_AND_WAIT) (page 5.2-33). 
When the data received is incomplete 
vall PROCESS_DATA_INCOMPLETE(RCB) (page 5.2- 36). 
When the RCB.MC RECEIVE _BUFFER is empty 
Put the WHAT_RECEIVED indicator in the MC_RECEIVE_BUFFER 
of the current RCB. 
Call the UPM_MAPPER (page 5.2-46) to save an 
indication that the end of the logical message was received. 
When the RCB.MC_RECEIVE_BUFFER is not empty, but does not contain data, 
Clear the MC_RECEIVE_BUFFER in the current RCB. 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the RESOURCE_FAILURE_NO_RETRY return code in the 
MC_RECEIVE_BUFFER of the current RCB. 
Else | 
Call PROCESS_ERROR_OR_FAILURE_RC (page 5.2-31)} 
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PROCESS_ERROR_OR_FAILURE_RC 


FUNCTION: This procedure is invoked after PS.MC has issued a RECEIVE_AND_WAIT to which 
has been returned a RETURN_CODE value other than OK. Processing of the return 
code continues in other procedures, depending upon the return code. 


INPUT: The RCB' corresponding to the conversation specified in the verb being proc- 
essed, and the RECEIVE_AND_WAIT return code to be processed 


OUTPUT: A return code value is placed in RCB.MC_RECEIVE_BUFFER. 


NOTES: Certain return codes are invalid if RCB.MC_RECEIVE_BUFFER is not empty, and, 
if received at such a time, indicate that the partner LU has committed a pro- 
tocol violation. Depending upon the return code, PS.MC may end the mapped 
conversation. 


A return code on RECEIVE_AND_WAIT of ALLOCATION_ERROR cannot occur if prior 
information has been received on the specified mapped conversation. 


A return code on RECEIVE_AND_WAIT of PROG_ERROR_PURGING or SVC_ERROR_PURGING 
cannot occur if MC_RECEIVE_BUFFER is not empty. It can occur only if the 
RECEIVE_AND_WAIT was issued by PS.MC while the mapped conversation was in SEND 
state. (The partner transaction program or LU that issued the *_ERROR_PURGING 
information was in RECEIVE state.) Since the mapped conversation was in the 
SEND state locally, no information can be in RCB.MC_RECEIVE_BUFFER. 


The return codes that reference this note can be received at any time and are 
valid regardless of the status of RCB.MC_RECEIVE BUFFER. 


A return code of *_ERROR_TRUNC cannot be received on the RECEIVE_AND_WAIT 
issued by this procedure because it can only be received following a 
RECEIVE_AND_WAIT in which a WHAT_RECEIVED value of DATA_INCOMPLETE is 
returned. (This procedure is not invoked after a DATA_INCOMPLETE indicator 
has been received. ) 


Referenced procedures, FSMs, and data structures: 


PS SPS page 5.3-35 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC page 5.2-41 
RCVD_SVC_ERROR_PURGING page 5.2-42 
UPM_MAPPER : page 5.2-46 
PROTOCOL_ERROR_PROC page 5.2-47 
RCB page A-7 


Select based on the RECEIVE_AND_WAIT return code being processed: 
When 4LLGCATION_ERROR (see Note 2) 
Put the return code in RCB.MC_RECEIVE_BUFFER. 
When DEALLOCATE_NORMAL 
If RCB.MC_RECEIVE BUFFER is empty then 
Put the return code in RCB.MC_RECEIVE_BUFFER. 
Else (optional check when receiving data; see Note 1) 
Replace the contents of RCB.MC_RECEIVE_BUFFER by the return 
code value RESOURCE_FAILURE_NO_RETRY. 
Optionally log implementation-dependent error data. 
When DEALLOCATE_ABEND_PROG 
If RCB.MC_RECEIVE_BUFFER is empty then 
Put the return code DEALLOCATE_ABEND in RCB.MC_RECEIVE_ BUFFER. 
Else (optional check when receiving data; see Note 1 ) 
Replace the contents of RCB.MC_RECEIVE_BUFFER by the return 
code RESOURCE_FAILURE_NO_RETRY. 
Optionally log implementation-dependent error data. 
When PROG_ERROR_PURGING (see Note 3) 
Put the return code parameter in RCB.MC_RECEIVE_BUFFER. 
Call UPM_MAPPER (page 5.2-46) to record a remotely detected 
error of the type indicated by the return code parameter. 


Chapter 5.2. Presentation Services--Mapped Conversation Verbs 5.2-31 


PROCESS_ERROR_OR_FAILURE_RC 


When PROG_ERROR_NO_TRUNC 
If RCB.MC_ RECEIVE_ BUFFER is empty then 
Put the return code in RCB.MC _RECEIVE _BUFFER. 
Call UPM_MAPPER (page 5.2-46) to record a remotely detected 
error of the type indicated by the return code. 
Else (optional check when receiving data; see Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Replace the contents of RCB.MC_RECEIVE_BUFFER by the return 
code RESOURCE_FAILURE_NO_RETRY. 
When DEALLOCATE_ABEND_SVC, DEALLOCATE_ABEND_TIMER (see Note 4) 
Replace the contents of RCB.MC _RECEIVE _BUFFER by the return 
code RESOURCE_FAILURE_NO_ RETRY. 
When RESOURCE _FAILURE _RETRY; RESOURCE_FAILURE_NO_RETRY (see Note 4) 
Replace the contents of RCB.MC_ RECEIVE _BUFFER by the return code. 
When BACKED_OUT 
If RCB. MC_RECEIVE_BUFFER is empty then 
Call PS_SPS (syne point manager, Chapter 5.3). 
Put the return code in RCB.MC_RECEIVE_BUFFER. 
Else (optional check when receiving data; see Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Replace the contents of RCB.MC_RECEIVE_BUFFER by the return 
code RESOURCE_FAILURE_NO_RETRY. 
When SVC_ERROR_NO_TRUNC (see Note 4) 
Clear the RCB.MC_RECEIVE_BUFFER. 
Call RCVD_SVC_ERROR_TRUNC_NO_TRUNC (page 5.2-41) 
to process the return code. 
When SVC_ERROR_PURGING (see Note 3) 
Call RCVD_SVC_ERROR_PURGING (page 5.2-42) to get 
and process error data from the partner LU. 
Put the code it returns in RCB.MC_RECEIVE BUFFER. 
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PROCESS_DATA_COMPLETE 


FUNCTION: This procedure is invoked when PS.MC issues a RECEIVE_AND_WAIT and a value of 
DATA_COMPLETE is returned in the WHAT_RECEIVED field of the RECEIVE_AND_WAIT. 
The purpose of this procedure is to process the received data. 


The data received in the RECEIVE_AND_WAIT is a logical record. It may be the 
first or only logical record in a GDS variable. Alternatively, it may be a 
subsequent logical record in a GDS variable containing multiple logical 
records. A subsequent logical record does not carry a GDS ID field. 


If the MC_RECEIVE_ BUFFER is empty, the data in the RECEIVE_AND_WAIT is the 
initial or only logical record in a GDS variable. This procedure checks the 
GDS ID in’ the logical record and calls the appropriate procedure to process 
the data carried in the DATA field of the logical record. 


If the MC_RECEIVE_BUFFER contains a map name but no data, the data’ in the 
RECEIVE_AND_ WAIT is again the initial or only logical record in a_ GDS vari- 
able. The GDS variable following a Map Name GDS variable has to contain 
application or user control data. 


If the MC_RECEIVE_BUFFER contains incomplete data or a map name and incomplete 
data (i.e., the last logical record in a GDS variable that contains multiple 
logical records has not been received), the appropriate procedure is called to 
add the data carried in the DATA field of the subsequent logical record to the 
data already contained in the MC_RECEIVE_BUFFER If the subsequent logical 
record is the last logical record in the GDS variable, additional processing 
is performed. 


The RCB associated with the mapped conversation specified in the current verb 
issued by the transaction program and the RECEIVE_AND_WAIT (issued by PS.MC) 
that contains the data to be processed 


OUTPUT: Depending upon the data received, the MC_RECEIVE_BUFFER may be updated. See 
the procedures called for specific outputs. 


Referenced procedures, FSMs, and data structures: 


SEND_SVC_ERROR_PURGING page 5.2-45 
PROTOCOL_ERROR_ PROC page 5.2-47 
PROCESS MAPPER_RETURN_CODE page 5.2-35 
UPM_MAPPER page 5.2-46 
RCB page A-7 


If the MC_RECEIVE_BUFFER for the current conversation is empty (no map name) then 
Select based on the type of GDS variable in the passed data (first record): 
When a Map Name GDS variable 
If the LU receiving the map name supports mapping and the TP for this 
conversation supports mapping then 
Put the unmapped map name in the MC_RECEIVE_BUFFER (data incomplete). 
Else (the LU or TP doesn't support mapping) 
Call SEND_SVC_ERROR_PURGING (page 5.2-45) to 
handle the invalid map name and mapping request. 
When an Application Data GDS variable 
Put the passed unmapped data and an indication that FM headers are 
not included in the data in the MC_RECEIVE_BUFFER. 
If data is not continued in the next logical record (only one record) then 
Call the UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
to map the received data, specifying that FMH data is not included. 
(No mapping will occur if no map name is found.) 
Call PROCESS _MAPPER_RETURN_CODE (page 5.2-35). 
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PROCESS _DATA_COMPLETE 


When a User Control Data GDS variable 
If the LU for the current conversation supports FMH data and 
the TP for the current conversation supports FMH data then 
Put the passed unmapped data and an indication that FM headers are 
included in the data in the MC_RECEIVE_BUFFER. 
If the data is not continued in the next record (one logical record) ther 
Call the UPM_MAPPER(8CB.MAPPER_SAVE_AREA) (page 5.2-46) 
to get the map name and to map the received dsta, specifying that FMH 
data 1s included. (No mapping will occur if no map name is found. ) 
Call PROCESS_MAPPER_RETURN_CODE(RCB) (page 5.2-35). 
Flse (the LU or TP doesr'* Support FMH-data) 
Call SEND_SVC_ERROR_PURGING (page 5.2-45) 
to perform service error purging, and to notify the partner LU. 
When a Null Structured Data GDS variable 
Do nothing. 
When an Error Data GDS variable, optionally 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the return code in the MC_RECEIVE_BUFFER of the current RCB. 
When the GDS ID jis invalid 
Call SEND_SVC_ERROR_PURGING (page 5.2-45) to 
handle the invalid GDS ID (no such variable type). 
Else (the MC_RECEIVE_BUFFER is not empty) 
If the buffer element in the MC_RECEIVE_BUFFER is a map name then 
Select based on the contents of the passed RECEIVE_AND_WAIT data: 
When the GDS ID indicates an Application Data variable 
Add the passed data and an indication that FM headers are 
not included in the data to the unmapped map name in the 
MC_RECEIVE_ BUFFER. 
If the data is not continued in the next record (one record) then 
Call the UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
to map the received data in the MC_RECEIVE_BUFFER. 
Call PROCESS _MAPPER_RETURN_CODE (page 5.2-35). 
When the GDS ID indicates a User Control Data GDS variable 
If the LU for the current conversation supports FMH data and 
the TP for the current conversation supports FMH data then 
Add the passed data and an indication that FM headers are included 
in the data to the unmapped map name in the MC_RECEIVE_BUFFER. 
If the data is not continued in the next record (only one record) then 
Call the UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
to map the received data in the MC_RECEIVE_BUFFER. 
Call PROCESS_MAPPER_RETURN_CODE (page 5.2-35). 
Else (the LU or TP doesn't support FMH data) 
Call SEND_SVC_ERROR_PURGING (page 5.2-45) 
to perform service error purging, and to notify the partner LU. 
When the GDS ID is invalid for a map name buffer element, optionally 
Purge the MC_RECEIVE_BUFFER for the current RCB. 
CALL PROTOCOL_ERROR_PROC (page 5.2-47) to 
deallocate the conversation. 
Put the return code in the MC_RECEIVE_BUFFER of the current RCB. 
Else (the buffer element indicates continued data, with or without a map name) 
Add the passed data to the data contained in the MC_RECEIVE_BUFFER. 
If the data is not continued in the next logical record then 
Call the UPM_MAPPER (page 5.2-46) to map the contents 
of the MC_RECEIVE_BUFFER (a complete variable), specifying the map 
name, if any» and that FM header data is included. 
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PROCESS_MAPPER_RETURN_CODE 
PROCESS_MAPPER_RETURN_CODE 


FUNCTION: This procedure determines whether the mapper mwas successful in mapping data. 
It is invoked after the mapper has been called to process data received from 
the partner transaction program. 


INPUT: The RCB corresponding to the mapped conversation over which the data to be 
mapped flowed; and a structure containing information that is both supplied 
to, and returned from, the mapper 


OUTPUT: If the mapper was able to successfully map the received data, the mapped data, 
along with a locally Known map name provided by the mapper and an indication 
of the format of the mapped data, is placed in the MC_RECEIVE_ BUFFER. If map- 
ping was unsuccessful, PS.MC performs service error purging processing to 
notify the partner LU that the received data could not be mapped. (See "Serv- 
ice Errors Detected tn Received Data" on page 5.2-14.) 


NOTES: 1. If the mapper was successful in mapping the received data, it always provides 
to PS.MC a protocol boundary map name Known to the local transaction program. 
The map name is supplied by the mapper even when it was invoked without a map 
name (in which case, the mappeg uses a previously received map name). If map- 
ping is off, the mapper supplies a null map name, which is passed to the 
transaction program. 


2. If the mapper encountered an error in mapping the data, it provides to PS.MC 
the map name, Known to the remote LU, that was in effect when the mapper was 
invoked. PS.MC places the map name in an Error Data GOS variable, which is 
sent to the partner LU to notify it of the mapping failure. 


3. A return code of MAP_NOT_FOUND carmmot be returned from the mapper if the 
mapper is invoked without a map name. If the mapper is invoked without a map 
name, it determines that it is to use a previously received map name. If the 
map name had been unknown to the mapper, this fact would have been discovered 
as a result of the earlier mapper invocation. 


Referenced procedures, FSMs, and data structures: 


SEND_SVC_ERROR_PURGING page 5.2~-45 
PROTOCOL_ERROR_ PROC page 5.2-47 
RCB page A-7 


Select based on the return code from the mapper: 
When mapping was successful 
Put the mapped map name, an indication that FM headers are included 
in the data, and the mapped data in the MC_RECEIVE_BUFFER. 
When mapping failed to execute successfully 
Call SEND_SVC_ERROR_PURGING (page 5.2-45) 
specifying the current RCB and the error type. 
When the provided map name was not found 
Call SEND_SVC_ERROR_PURGING (page 5.2-45) 
specifying the current RCB and the error type. 
When the map name was a cuplicate (optional processing for receive only) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) to 
deallocate the current conversation. 
Put a duplicate map name return code in the current MC_RECEIVE BUFFER. 
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PROCESS DATA_INCOMPLETE 


This procedure is invoked when PS.MC issues a RECEIVE _AND_WAIT as a result of 
a mapped conversation verb issued by the transaction program. PS.MC has exam- 
ined the value returned in the WHAT_RECEIVED field of the RECEIVE_ANO_WAIT, 
determined that the value received is DATA_INCOMPLETE, and has discarded the 
incomplete logical record returned in the RECEIVE _AND_WAIT. 


This procedure purges the MC_RECEIVE_BUFFER of any data that has been received 
via one or wore prior RECEIVE_AND _WAITs. It then issues a RECEIVE _AND_WAIT to 
determine the reason for the logical record being truncated. Processing con- 
tinues based upon the RETURN_CODE value received in the RECEIVE_ANO_WAIT. 


INPUT : The RCB corresponding to the resource specified in the RECEIVE _AND_WAIT in 
which DATA_INCOMPLETE was returned. | 


: This procedure issues a RECEIVE _AND_WAIT. Depending upon the RETURN_CODE val- 
ue returned on the RECEIVE_AND WAIT, a return code buffer element may be 
inserted into the MC_RECEIVE_BUFFER. 


RETURN_CODE values of DEALLOCATE_ABEND_PROG, PROG_ERROR_TRUNC, and BACKED_OUT 
following a DATA_INCOMPLETE notification indicate that the partner LU has con- 
mitted a protocol violation by allowing the transaction program to truncate 
data. This should never occur at the mapped conversation protocol boundary. 
The PS.MC at the partner LU is allowed to truncate a logical record with 
SVC_ERROR_TRUNC, for instances the transaction program is not. 


Referenced procedures, FSMs», and data structures: 


RCVD_SVC_ERROR_TRUNC_NO_TRUNC page 5.2-41 
PROTOCOL _ERROR_PROC page 5.2-47 
PS _VERB_ROUTER page §.0-11 
RCB page A-~-7 


Clear the RCB.MC_RECEIVE_BUFFER. 
Call the PS_VERB_ROUTER (Chapter 5.0) to issue a 
RECEIVE_ANO_WAIT verb to get the return code that explains why the 
data was incomlete. 
If a request to send data was received from the remote TP then 
Save an indication of the request to be returned later. 
Select based on the RECEIVE_AND_WAIT return code: 
When the return code is SVC_ERROR_TRUNC 
Call RCVD_SVC_ERROR_TRUNC_NO_TRUNC to do service error processing 
(page 5.2-41). 
When the return code is DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER 
Put the return code RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
When the return code is RESOURCE_FAILURE_RETRY or RESOURCE _FAILURE_NO_RETRY 
Put the return code in the MC_RECEIVE_BUFFER of the current RCB. 
When the return code is DEALLOCATE_ABEND_PROG, optionally do the folloning: 
Put the return code RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
Log implementation-dependent error data in the system error log. 
When the return code is PROG_ERROR_TRUNC or BACKED_OUT, optionally do the following: 
Call PROTOCOL_ERROR_PROC (page 5.2-47) to deallocate the 
current conversation. 
Put the return code in the MC_RECEIVE_BUFFER of the current RCB. 
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MC_REQUEST_TO_SEND_ PROC 


FUNCTION: 


INPUT: 


NOTE: 


This procedure processes MC_REQUEST_TO_SEND verbs. 


PS.MC issues a REQUEST_TO_SEND verb against the resource specified in the 
MC_REQUEST_TO_SEND and returns control to the transaction program. 


MC_REQUEST_TO_SEND verb parameters. 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_REQUEST_TO_SEND verb. A state check is performed by 
PS.CONV (Chapter 5.1) during its processing of the REQUEST_TO_SEND verb. 


Referenced procedures, FSMs, and data structures: 


PS_VERB_ROUTER 


page 5.0-11 


Call PS_VERB_ROUTER (Chapter 5.0) to issue a 
REQUEST_TO_SEND verb for the current conversation. 
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MC_SEND_DATA_PROC 


‘FUNCTION: 


INPUT: 


OUTPUT: 


NOTES: 


1. 


This procedure processes MC_SENOD_DATA verbs. 


This procedure causes the mapper to be invoked. If the mapper is successful 
in mapping the data contained in the MC_SEND_DATA, or if the mapper determines 
that mapping is not being performed, the output data frow the mapper is placed 
in an Application Data or User Control Data GDS variable (the variable may 
contain one or more logical records). The mapper may also return to PS.MC a 
map name that is to be sent to the partner LU, in which case PS.MC also cre- 
ates a Map Name GDS variable that precedes the data GDS variable. This proce- 
dure then issues a SEND_DATA containing the GDS variable(s). 


PS.MC sets the return code field in the MC_SEND_DATA based upon the value 
returned in the SEND_DATA. Some return codes, such as OK, are placed in the 
MC_SEND_DATA umchanged. Others, such as DEALLOCATE_ABEND_PROG, are trans- 
formed to another value before being placed in the MC_SEND_DATA. In addition, 
some return codes cause PS.MC to perforw further processing. For example, 
when PS.MC receives a return code of PROG_ERROR_PURGING to its SEND_DATA, it 
invokes the mapper to inform that procedure that the partner transaction pro- 
gram detected an error. (See "Mapper Invocation" on page 5.2-9.) When a 
return code of SVC_ERROR_PURGING is received, PS.MC performs the processing 
necessary to determine what type of service error the PS.MC component at the 
partner LU encountered. A return code reflecting the type of error is 
returned to the local transaction program in the MC_SEND_DATA. (See “Process-~- 
ing of a Service Error Detected by Partner LU" on page 5.2-17.) 


MC_SEND_DATA verb parameters (See SNA Transaction Programmer's Reference Man- 
val for LU Type 6.2.) 


PS.MC issues a SEND_DATA verb. It sets fields in the MC_SEND_DATA based upon 
the corresponding values returned in the SEND_DATA. 


PS.MC performs a check to determine if the conversation is in an appropriate 
state to receive an MC_SEND_DATA. This is unlike its processing of most 
mapped conversation verbs, in that PS.MC generally does not perform this state 
check, but instead allows it to be performed by PS.CONV (Chapter 5.1). PS.MC 
performs the state check, rather than deferring it, for the following reasons: 
unlike other verbs, the MC_SEND_DATA causes PS.MC to perform some amount of 
processing before issuing a basic conversation verb. By PS.MC performing the 
state check, any state errors are detected before the processing is performed. 
In addition, if the data provided in the MC_SEND_DATA could not be mapped by 
the mapper procedure, no basic conversation verb is issued; in order to catch 
any state errors, PS.MC has to perform the state check. 


The processing that PS.MC performs as a result of receiving a return code of 
SVC_ERROR_PURGING involves issuing one or more RECEIVE_AND WAIT verbs. 
REQUEST_TO_SENO_RECEIVED information may be returned on the 
RECEIVE_AND_WAIT(s), and, if this is the case, the MC_SEND_DATA is updated to 
reflect this information. 


— Referenced procedures, FSMs» and data structures: 


RCVD_SVC_ERROR_ PURGING page 5.2-42 
PS_SPS . page 5.3-35 
PS_VERB_ROUTER page 5.0-11 
UPM_MAPPER page 5.2-46 
SEND_BUFFER page 5.2-48 
RCB page A-7 
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MC_SEND_DATA_PROC 


Find the RCB for the resource specified in the MC_SEND_DATA verb. 
If the resource is in a state to receive data (Chapter 5.1) then 
Call the UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
to map the data to be sent, specifying the map name and whether or not the data 
contains FM header data (all from the verb). 
Select based on the return code from the mapper: 
When the mapper return code is MAP_NOT_FOUND 
Set the MC_SEND_DATA return code to MAP_NOT_FOUND. 
When the mapper return code is MAP_EXECUTION_FAILURE 
Set the MC_SEND_DATA return code to MAP_EXECUTION_ FAILURE. 
Optionally, log implementation-dependent error data in system error log. 
When the mapping was successful 
If a map name was returned from the mapper then 
Create a Map Name GDS variable for the map name and put it in the SEND_BUFFER 
Create a GDS variable that contains the data passed with the verb, 
which has been successfully mapped. The GDS variable, depending on the 
amount of data», may consist of one logical record or of multiple continued 
logical records. Only the first logical record will carry the GDS ID 
indicating either a User Control Data or an Application Data GDS variable type. 
Put, or add, the data GDS variable in» or to, the SEND_BUFFER. 
Call the PS_VERB_ROUTER (Chapter 5.0) to issue a 
SEND_DATA verb,» specifying the SEND_BUFFER and the length of the data 
to send, for the current RCB. 
If the SEND_DATA verb processing resulted in a saved request in the 
current RCB, from the remote TP, to send data then 
Save this request to be returned to the local TP on the MC_SEND_DATA verb. 
Select based on the SEND_DATA return code: 
When OK do nothing. 
When ALLOCATION_ERROR, RESOURCE_FAILURE_RETRY, or RESOURCE_FAILURE_NO_RETRY 
Set the MC_SEND_DATA return code to the SEND_DATA return code. 
When DEALLOCATE_ABEND_PROG 
Set the MC_SEND_DATA return code to DEALLOCATE_ABEND. 
When DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER 
Set the MC_SEND_DATA reurn code to RESOURCE_FAILURE_NO_RETRY. 
When PROG_ERROR_PURGING 
Set the MC_SEND_DATA return code to the SEND_DATA return code. 
Call UPM_MAPPER(RCB.MAPPER_SAVE_AREA) (page 5.2-46) 
to notify the mapper of the remotely detected error. 
When BACKED_OUT : 
Call PS_SPS (Chapter 5.3). 
Set the MC_SEND_DATA return code to the SEND_DATA return code. 
When SVC_ERROR_PURGING 
Call RCVD_SVC_ERROR_PURGING passing the current RCB and the 
SEND_DATA return code (page 5.2-42). 
If a request to send has been received from the remote TP and not 
returned on a prior MC_CONFIRM, MC_RECEIVE_AND_WAIT, MC_SEND_DATA, 
or MC_SEND_ERROR verb then 
Return a request-to-send-received indication to the local TP on 
the MC_SEND_DATA verb. 
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MC_SEND_ERROR_PROC 


This procedure processes MC_SEND_ERROR verbs. 


MC_SEND_ERROR verb parameters (See SNA Jransaction Programmer's Reference 
Manual for LU Type 6.2.) : 


A return code indicating the result of the verb execution. An indication that 
a request to send has been received from the remote TP may also be returned. 


PS.MC performs no check to determine if the conversation is in an appropriate 
state to receive an MC_SEND_LERROR. A state check is performed by PS.CONV 
(Chapter 5.1) during its processing of the SEND_ERROR verb. 


The processing that PS.MC performs as a result of receiving a return code of 
SVC_ERROR_PURGING involves issuing one or more RECEIVE_AND_WAIT verbs. A 
request to send from the remote TP may be returned on a RECEIVE_AND_WAIT and, 
if this is the case, an indication of the request is passed to the local TP. 


Referenced procedures, FSMs, and data structures: 


RCVD_SVC_ERROR_ PURGING page 5.2-42 
PS_SPS page 5.3-35 
PS_VERB_ROUTER page 5.0-11 
UPM_MAPPER page 5.2-46 
RCB page A-7 


Find the RCB for the specified conversation. 
Clear RCB.MC_RECEIVE BUFFER. 
Call PS_VERB_ROUTER (Chapter 5.0) to issue a SEND_ERROR 
verb for the current conversation without data for the system error log 
and indicating that the request originated from the transaction program. 


Select based on the return code from SEND _ERROR: 
When OK 
Set the return code to the code returned by SEND_ERROR. 
If the conversation is in send state (Chapter 5.1) then 
Call UPM_MAPPER (page 5.2-46) to record a locally detected 
error of the type PROG_ERROR_NO_TRUNC. 
Else 
Call UPM_MAPPER (page 5.2-46) to record a locally detected 
error of the type PROG_ERROR_PURGING. 
When PROG_ERROR_PURGING 
Set the return code to the code returned by SEND_ERROR. 
Call UPM_MAPPER (page 5.2-46) to record a remotely detected 
error of the type indicated by the return code from SEND_ERROR. 
When ALLOCATION_ERROR, DEALLOCATE_NORMAL, RESOURCE_FAILURE_RETRY, or 
RESOURCE_FAILURE_NO_RETRY 
Set the return code to the code returned by SEND_ERROR. 
When DEALLOCATE_ABEND_PROG 
Set the return code to DEALLOCATE_ABENO. 
When DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER 
Set the return code to RESOURCE _FAILURE_NO_RETRY. 
When BACKED_OUT 
Call PS_SPS (Chapter 5.3). 
Set the return code to the code returned by SEND_ERROR. 
When SVC_ERROR_PURGING 
Call RCVD_SVC_ERROR_PURGING (page 5.2-42). 
Set the return code to the code returned by RCVD_SVC_ERROR_PURGING. 


If a request to send has been received from the remote TP and not 
indicated to the local TP on a prior MC_CONFIRM, MC_RECEIVE_AND_WAIT, 
MC_SEND_DATA, or MC_SEND_ERROR verb then 

Return a request-to-send-received indication to the local TP 


(see SNA Transaction Programmer's Reference Manual for LU Tvpe 6.2). 
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RCVD_SVC_ERROR_TRUNC_NO_TRUNC 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC 


FUNCTION: This procedure is invoked when a return code of SVC_ERROR_TRUNC or 
SVC_ERROR_NO_TRUNC is returned by a RECEIVE _ANO_WAIT verb. This return code 
indicates that the partner LU detected a map execution failure while sending 
data. All or only part of the date may have been sent. Any data that was 
received prior to the error is purged. Error information is optionally placed 


in the system error log, but the local transaction program is not informed of 
the error. 


INPUT: The RCB associated with the mapped conversation on which the service error was 
detected and the SVC_ERROR_TRUNC or SVC_ERROR_NO_TRUNC return code 


NOTES: 1. If the expected Error Data GDS variable is not received, or is received but 
indicates an error condition that is invalid in the present situation, the 
partner LU has committed a protocol violation. If the protocol violation 
occurred as a result of the partner LU allowing the mapped conversation to be 
prematurely ended without having sent the error data, PS.MC simply logs the 
error. Otherwise, PS.MC ends the mapped conversation. In either case, PS.MC 
inserts a return code of RESOURCE _FAILURE_NO_RETRY tm RCB.MC_RECEIVE BUFFER. 


2. A return code of RESOURCE_FAILURE_RETRY or _NO_RETRY can occur at any time and 
does not indicate that the partner LU committed a protocol violation. 


Referenced procedures, FSMs, and data structures: 


UPM_MAPPER page 5.2-4%6 
PS _VERB_ROUTER page 5.0-11 
PROTOCOL_ERROR_ PROC page 5.2-%7 
RCB page A-7 

ERROR_DATA_STRUCTURE page 5.2-48 


Call UPM_MAPPER (page 5.2-46) to record a remotely 
detected error of the type SVC_ERROR_TRUNC or SVC_ERROR_NO_TRUNC 
as indicated by the input parameter. 
Call PS_VERB_ROUTER (Chapter 5.0) to issue a RECEIVE_AND_WAIT 
verb for the current conversation, specifying a wait for 
the receipt of a complete logical record. 
Select based on the return code from RECEIVE_AND_WAIT: 
When OK 
Interpret the data returned by the RECEIVE_AND_WAIT verb as 
an ERROR_DATA_STRUCTURE . 
If RECEIVE_AND_WAIT returns DATA_COMPLETE, the GDS_ID in 
ERROR_DATA_STRUCTURE indicates that the structure contains 
error data (see Appendix H)}, and ERROR_DATA_STRUCTURE .ERROR_CODE 
indicates a map execution failure (see Appendix H) then 
Optionally log implementation-dependent error data. 
Else (optional check when receiving data; see Note 1 ) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the return code RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE BUFFER of the current RCB. 
When RESOURCE_FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY (see Note 2) 
Put the return code from the RECEIVE_ANO_WAIT verb in the 
MC_RECEIVE_ BUFFER of the current RCB. 
When PROG_ERROR_NO_TRUNC, SVC_ERROR_NO_TRUNC, or BACKED_OUT 
(optional check when receiving data; see Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the return code RESOURCE _FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
When DEALLOCATE_NORMAL, DEALLOCATE_ABEND_PROG, DEALLOCATE_ABEND_SVC, or 
DEALLOCATE_ABEND_TIMER (optional check when receiving data; see Note 1) 
Put the return code RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
Optionally log implementation-dependent error data. 


Chapter 5.2. Presentation Services--Mapped Conversation Verbs 52-4) 


RCVD_SVC_ERROR_ PURGING 


RCVD_SVC_ERROR_PURGING 


FUNCTION: This procedure is invoked when PS.MC issues a basic conversation verb in which 
a return code of SVC_ERROR_PURGING is returned. Unlike SVC_ERROR_TRUNC and 
SVC_ERROR_NO_TRUNC, the SVC_ERROR_PURGING return code can be returned ona 
verb issued while the mapped conversation is in either send or receive state. 


INPUT: The RCB corresponding to the specified conversation. 


OUTPUT: A return code reflecting the outcome of the service error processing. 


NOTES: 1. If the expected Error Data GDS variable is not received, the partner LU has 

committed a protocol violation. The checks for these violations given below 

| are optional. If the protocol violation occurred as a result of the partner 

| LU allowing the mapped conversation to be prematurely ended without having 

sent the error data, PS.MC simply logs the error. Otherwise, PS.MC ends the 

mapped conversation. In either case, PS.MC =returns the code 
RESOURCE_FAILURE_NO_RETRY. | 


A return code of RESOURCE_FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY can occur 
at any time and does not indicate that the partner LU committed a protocol 
violation. 


Referenced procedures, FSMs;, and data structures: 


UPM_MAPPER page 5.2-46 
PS VERB_ROUTER page 5.0-11 
PROCESS_ERROR_DATA page 5.2-43 
GET_SEND_INDICATOR | page 5.2-44 
PROTOCOL_ERROR_PROC page 5.2-47 
RCB page A-7 

ERROR_DATA_STRUCTURE page 5.2-48 


Call UPM_MAPPER (page 5.2-46) to record a remotely 

detected error of the type SVC_ERROR_PURGING as indicated by the 
return code from the last verb issued. 
Call PS_VERB_ROUTER (Chapter 5.0) to issue a RECEIVE_ AND WAIT | 
verb for the current conversation, specifying a wait for 

the receipt of a complete logical record. 
Select based on the return code from RECEIVE_AND WAIT: 

When OK 

Interpret the data returned by the RECEIVE_AND_WAIT verb as 
an ERROR_DATA_STRUCTURE. 

If RECEIVE_AND_WAIT returns DATA_ COMPLETE and the GDS_ID of 
ERROR_DATA_STRUCTURE indicates that the structure contains 
error data then 

Call PROCESS_ERROR_DATA (page 5.2-43) and 

pass it the ERROR _DATA_STRUCTURE. 

Set the return code to the code returned by PROCESS ERROR_DATA. 

If the return code is not RESOURCE_FAILURE_NO_RETRY then 
Call GET_SEND_INDICATOR (page 5.2-44). 

Else (Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Set the return code to RESOURCE_FAILURE_NO_RETRY. 
When RESOURCE_FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY (Note 2) 

Set the return code to the code returned by RECEIVE_AND_WAIT. 

When PROG_ERROR_NO_TRUNC, SVC_ERROR_NO_TRUNC, or BACKED_OUT (Note 1) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 

to deallocate the current conversation. 

Set return code to RESOURCE_FAILURE_NO RETRY. 

When DEALLOCATE_NORMAL, DEALLOCATE_ABEND_PROG, 

DEALLOCATE_ABEND_SVC or DEALLOCATE_ABEND_TIMER (Note 1) 
| Optionally log implementation-dependent error data. 
Set the return code to RESOURCE_FAILURE_NO_RETRY. 
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PROCESS_ERROR_DATA 
PROCESS_ERROR_DATA 


This procedure is invoked during the processing that PS.MC performs as a 
result of receiving a return code of SVC_ERROR_PURGING. It is called after 
receiving the Error Data 6DS variable that follows the service error notifica- 
tion. The purpose of this procedure is to process the information carried in 
the Error Data GOS variable. 


The Error Data GOS variable received from the remote TP 


If the Error Data GDS variable contains no invalid values, this procedure 


returns a code that reflects the information carried in the error data and 
logs the error information in the system error log. If the error data con- 
tains an invalid value, PS.MC ends the mapped conversation. 


When the Error Data 60S variable indicates MAP_NOT_FOUND 3 or 
MAP_EXECUTION_FAILURE, the map name that caused the error is carried in the 
ERROR_PARM field of the Error Data GDS variable. When the Error Data GDS var- 
iable indicates INVALID_GDS_ID, the GDS_ID that specifies a function not sup- 


ported by the partner LU or transaction program is carried in the ERROR_PARM 
field. 


Referenced procedures, FSMs, and data structures: 
PROTOCOL_ERROR_PROC page 5.2-47 


ERROR_DATA_STRUCTURE page 5.2-48 


Select based on ERROR_DATA_STRUCTURE .ERROR_CODE: 
When it indicates an invalid GDS_ID (see Appendix H) 
Select based on the GDS_ID in ERROR_DATA_STRUCTURE .ERROR_PARM: 
When it indicates user control data (see Appendix H) 
Set the return code to FMH_DATA_NOT_SUPPORTED. 
Optionally log implementation-dependent error data. 
When it indicates map name (see Appendix H) 
Set the return code to MAPPING NOT_SUPPORTED. 
Optionally log implementation-dependent error data. 
Otherwise (optional check when receiving data) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the return code RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
When it indicates map not found (see Appendix H) 
Set the return code to MAP_NOT_FOUND. 
Optionally log implementation-dependent error data. 
When it indicates map execution failure (see Appendix H) 
Set the return code to MAP_EXECUTION_FAILURE. 
Optionally log implementation-dependent error data. 
Otherwise (optional check when receiving data) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the return code RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
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GET_SEND_INDICATOR — 


5 . 2~-4G 


GET_SEND_ INDICATOR 


This procedure is invoked during the processing that PS.MC performs as a 
result of receiving a raturn code of SVC_ERROR_PURGING. This procedure is 
called after the Error Data 6DS variable that follows the service error 
notification has been received and processed. The purpose of this procedure 
is to receive the SEND indication that follows the Error Data 60S variable. 


The RCB that corresponds to the specified conversation 


A return code reflecting the results of the processing 


Referenced procedures, FSMs, and data structures: 


PS_VERB_ROUTER page 5.0-11 
PROTOCOL_ERROR_PROC page 5.2-47 
RCB | page A-7 


Call PS_VERB_ROUTER (Chapter 5.0) to issue a RECEIVE_ANO_WAIT 
verb for the current conversation, specifying a wait for 
the receipt of a complete logical record. 
Select based on the return code from RECEZVE_ANO_WAIT: 
When OK (optional check when receiving data) 
If RECEIVE_AND_WAIT returns NHAT_RECEIVED other than SEND then 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Set the return code to RESOURCE_FAILURE_NO_RETRY. 
When RESOURCE_FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY 
Set the return code to the code returned by RECEIVE_AND WAIT. 
Wnen DEALLOCATE_NORMAL, DEALLOCATE_ABEND_PROG, 
DEALLOCATE_ABEND_SVC, or DEALLOCATE_ABENOD_TIMER 
(optional check when receiving data) 
Set the return code to RESOURCE_FAILURE_NO_RETRY. 
Optionally log implementation-dependent error data. | 
When PROG_ERROR_NO_TRUNC, SVC_ERROR_NO_TRUNC, or BACKED_OUT 
(optional check when receiving data) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Set the return code to RESOURCE_FAILURE_NO_RETRY. 
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SEND_SVC_ERROR_PURGING 
SEND_SVC_ERROR_PURGING 


FUNCTION: This procedure performs service error purging processing. It is invoked when 
PS.MC receives a 6DS variable specifying a function not supported by either 
the LU or the transaction program associated with the mapped conversation over 
which the GDS variable flowed, or when PS.MC receives a 605 variable contain- 
ing an unrecognized GOS ID, or when data mapping is being performed and the 
mapper procedure has encountered an error in mapping the received data. 


INPUT ;: The RCB for the conversation on which the service error occurred; an error 
code specifying the type of error encountered; and an error parameter that 
provides more information about the error 


OUTPUT: If any of the verbs issued by this procedure do not complete successfully, the 
procedure inserts into the RCB.MC_RECEIVE_BUFFER an appropriate return code. 


NOTE : If mapping is supported and the mapper does not already Know about the error, 
the mapper is notified of the type of error encountered. The mapper is not 
invoked when the error encountered is a MAP_NOT_FOUND or MAP_EXECUTION_FAILURE 
condition--the mapper is already aware of the error. (The mapper discovered 
the error.) If the error encountered indicates MAPPING_NOT_SUPPORTED, no 
mapper exists. 


Referenced procedures, FSMs, and data structures: 


UPM_MAPPER page 5.2-46 
PS_VERB_ROUTER page 5.0-11 
PROTOCOL_ERROR_ PROC page 5.2~-47 
RCB page A-7 

ERROR_DATA_STRUCTURE page 5.2-48 


If the input error code indicates an invalid GDS_ID (see Appendix H) 
and the GDS_ID in the input error parameter does not indicate a map 
name (see Appendix H) then 

Call UPM_MAPPER (page 5.2-46) to record a remotely detected error 
of the type SVC_ERROR_PURGING, as indicated by the return code frow 
the last verb issued. 

Call PS_VERB_ROUTER (Chapter 5.0) to issue a SEND _ERROR 
verb for the current conversation, specifying error type SVC 
and implementation-dependent error log data. 

Select based on the return code from SEND_ERROR: 

When OK 
Create an ERROR _DATA_STRUCTURE (a single logical record) using the 
data in the parameters ERROR_CODE and ERROR_PARM. 
Call PS_VERB_ROUTER (Chapter 5.0) to issue a SEND_DATA 
verb to send the ERROR_DATA_STRUCTURE to the remote TP. 
Select based on the return code from SEND_DATA: 
When OK 
Call PS_VERB_ROUTER (Chapter 5.0) to issue a 
PREPARE_TO_RECEIVE verb for the current conversation with 
the type parameter set to FLUSH and locks set to SHORT. 
When RESOURCE_FAILURE_RETRY or RESOURCE_FAILURE_NO_RETRY 
Put the return code from SEND_DATA in the MC_RECEIVE BUFFER 
of the current RCB. 
When PROG_ERROR_PURGING, SVC_ERROR_PURGING, or BACKED _OUT 
(this check is optional when receiving data) 
Call PROTOCOL_ERROR_PROC (page 5.2-47) 
to deallocate the current conversation. 
Put the return code RESOURCE FAILURE NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
When DEALLOCATE_ABEND_SVC, DEALLOCATE_ABEND_TIMER, 
or DEALLOCATE_ABEND_PROG (optional check when receiving data) 
Optionally log implementation-dependent error data. 
Put the return code RESOURCE_FAILURE_NO_RETRY in the 
MC_RECEIVE_BUFFER of the current RCB. 
When DEALLOCATE NORMAL, RESOURCE _FAILURE_RETRY, or RESOURCE FAILURE _NO_ RETRY 
Put the return code from SENO_DATA in the MC_RECEIVE_ BUFFER 
of the current RCB. 
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UPM_MAPPER 


52-46 


UPM_MAPPER 


FUNCTION: 


INPUT : 


OUTPUT : 


This procedure, referred to elsewhere in this chapter as "the mapper'', per- 
forms mapping of data in = an implementation-defined way. The MAPPER_SAVE_AREA 
in the RCB for the current conversation contains information used in data map- 
ping, such as the currently effective map names (see "Map Names"' on page 
5.2-8). 


Refer to "Data Mapping and the Mapper" on page 5.2-8 for a detailed 
description of the processing that occurs when data is mapped. 


1. Reason why the mapper was invoked: 


e Data is to be sent to, or was received from, the partner LU. The map name 
supplied by the sending transaction program determines the kind of mapping 
that occurs. 


e An error occurred and was detected either remotely or locally. 


® A positive reply to CONFIRM or to SYNCPT was received. This positive con- 
firmation informs the mapper that any map names sent to the partner have 
been received and processed by it, and were not purged during error proc- 
essing. 


2. The polarity indicates whether send mapping or receive mapping is to be 
performed. This parameter is used when the wapper invocation is for data map- 
ping. 


3. FMH data indicator indicates mhether the passed data includes function 
management (FM) headers. The mapper requires this information in the event 
tiiat the same map name could cause a different mapping to take place depending 
upon whether the data being mapped includes FM headers. This parameter is 
used when the mapper invocation is for data mapping. 


4. Input map name contains the locally Known map name supplied by the trans- 
action program on an MC_SEND_DATA, if send mapping is to be performed, or the 
map name that flows in a Map Name GDS variable between LUs, if receive mapping 
is to be performed. This parameter is only used if the mapper invocation is 
for data mapping. 


5. Input data contains the data supplied by the transaction program on the 
MC_SEND_DATA verb for SEND wapping,» or data that flows in a data GDS variable 
for RECEIVE mapping. Again, this parameter is used only in data mapping. 


6. Error code informs the mapper of the type of error encountered (for exanm- — 
ple, SVC_ERROR_PURGING or PROG_ERROR_NO_TRUNC). This is needed when the 
mapper invocation is for an error occurrence. 


1. Output map name contains the "mapped" (global) map name that is sent to 
the partner LU if send mapping is performed, or the locally known map name 
that is passed to the transaction program if receive mapping was performed. 
This output is returned when the mapper invocation was for data mapping» and 
always after receive mapping. 


2. Output data contains the data that is sent to the partner LU for send map- 
ping, or the data that is passed to the transaction program for receive map- 
ping. Again, this data is returned if the the mapper was called for data 
mapping. 


3. Mapper return code indicates whether the mapper successfully performed the 
mapping or encountered problems, and is returned after data mapping = inv- 
ocations. 
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PROTOCOL_ERROR_PROC 


PROTOCOL_ERROR_ PROC 


FUNCTION: This procedure handles protocol error processing. It is invoked when PS.MC 
detects an architectural protocol error committed at the partner LU. 


INPUT: The RCB corresponding to the mapped conversation over which the protocol vio- 
lation occurred. 


NOTE : Error log data is entered into the system log by PS.CONV (Chapter 5.1) during 
its processing of the DEALLOCATE issued by this procedure. 


Referenced procedures, FSMs, and data structures: 
PS_VERB_ROUTER page 5.0-11 


RCB page A-7 


Call PS_VERB_ROUTER (Chapter 5.0) to issue a DEALLOCATE verb for the 
current conversation, specifying a deallocation type of ABEND_SVC and 
indicating that the resource ID is to be discarded. 

Optionally, implementation-dependent error data may be recorded in the 
system error log. 
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LOCAL DATA STRUCTURES 


ERROR_DATA_STRUCTURE 


ERROR_DATA_STRUCTURE: an instance of a GDS variable 
LL_LENGTH: the high-order bit is set to 0 indicating a single-segment record 
GDS_ID (see format of an Error Data GDS variable in Appendix H) 
DATA 
ERROR_CODE (see Appendix H) 
ERROR_PARM (see Appendix H) 


| SEND_BUFFER | | 


SEND_BUFFER: a buffer containing the mapped data to be sent. 
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Recovery from errors and failures is a cen- 
tral consideration in the design of trans- 
action programs. LU 6.2 provides optional 
services to aid transaction programs § in 
recovery from errors. A synchronization 


ERRORS, FAILURES, AND RECOVERY 


Errors and failures can be classified as: 


® Application  errors--these errors may 
occur frequently; recovery is part of the 
application design. In data entry, for 
instance, field validation and requests 
for repeated input are normal portions of 
the application logic. 


® Recoverable system errors--these errors 
occur frequently; recovery is part of the 
system logic. Bracket race errors are an 
example (see "Chapter 6.1. Data Flow Con- 
trol"); link-level retransmission is 
another. 


® Transaction program failures--transaction 
programs sometimes end abnormally. In a 
well-tested system, this will not occur 
frequently. Application-level recovery 
varies by application. See "Chapter 5.1. 
Presentation Services--Conversation 
Verbs" for details of abnormal termi- 
nation processing. 


@e Conversation failures--conversations will 
sometimes fail as a result of failure of 
the underlying sessions caused by the 
physical components over which the ses~ 
sions are carried. The reactivation of 
failed sessions is handled by system Llog- 
ics; see "Chapter 4. LU Network Services” 
for details. <Application-level recovery 
from conversation failure is discussed in 
more detail in SNA Transaction Prograim- 
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CHAPTER 5.3. PRESENTATION SERVICES--SYNC POINT SERVICES VERBS 


service is selected by the SYNC_LEVEL parame- 
ter in the ALLOCATE verb. This chapter is 
primarily concerned with the syne point syn- 
chronization services. 


® LU failures--LUs will sometimes fail by 
themselves or as a result of the failure 
of underlying hardware or software. Much 
of the recovery from LU failures, as seen 
by other LUs, is handled by the recovery 
of sessions that have failed. Other 
aspects of this recovery are the concern 
of sync point services. 


°® Local resource failures~-~-local resources 
(e.g.> files) will sometimes fail. If 
the local resource that fails is not pro- 
tected by the sync point service, recov- 
ery is an application-level 
responsibility. 


Applications are often designed as a sequence 
of logical units of work, each unit consist- 
ing of some changes to the resources under 
the control of the transaction program. Each 
logical unit of work (LUN) is recoverable by 
itself. The simplest case occurs when there 
is one LUW for a transaction program; recoy- 
ery can often then consist of running the 
transaction again from the beginning. LUNs 
are delimited by the start-up of a trans-~ 
action program and by execution of each 
SYNCPT verb. The SYNC_LEVEL(SYNCPT) service 
simplifies the design of transaction programs 
that use protected resources, since changes 
to those resources will be seen by the appli- 
cation transaction program as having occurred 
only after one LUM completes and before the 
next LUN begins. ? 


Figure 5.3-1 on page 5.3-2 illustrates the 
relationships among failures and recovery. 


Full support of sync point services in actual implementations includes provisions for syne 


chronizing local resources as well as distributed resources accessed through conversations. 
For completeness, this section sketches fully general syne point services. Detatis ef syne 
point services for local resources are not specified by SNA, but are implementation cetined. 


The sync point service is not always able to provide a consistent state for the protected 


resources. When this occurs, a heuristic decision is made. This sowetimes damages the LUK 
by making the states of its protected resources inconsistent. More cetetils about this are 
provided in "RESOURCE _FAILURE_*, Recovery, and Heuristic Decisions’ on page 5.215. 
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SYNC POINT CONCEPTS 


| The following are some terms that are used in 
| this chapter: 


e SYNCPT—A verb used by a transaction pro- 
gram (TP) to tnvoke syne point services. 
Sync point services coordinate the 
updates of distributed resources. Coor- 
dination is performed by the sending and 
receiving of presentation services (PS) 
headers by the sync point services compo- 
nent. The protocol allows recovery if 
messages are lost because of transaction 
program, conversation, or LU failures. 


® INITIATOR—The role of the local syne 
point services component when the TP 
issues the SYNCPT verb that begins the 
coordinated update of distributed 
resources. 


e AGENT—The role of the syne point serv- 
ices component that receives sync point 
requests from an initiator. 


5. 3-2 


CASCADED AGENT—An agent of an initiator 
that is itself an agent of another initi- 
ator; in other words, an agent may allo- 
cate other protected conversations. In 
this role an agent is responsible for 
propagating sync point requests to its 
cascaded agents. 


RESYNC—Recovery processing that is per- 
formed by syne point services after a 
failure of a session, transaction pro- 
gram, or LU. The resyne exchange 
includes exchanging log names and compar- 
ing LUW states. 


PRESENTATION SERVICES (PS) HEADER—The 
requests and replies that syne point | 
services components exchange to perform | 


SYNCPT verb processing. 


SNA Format and Protocol Reference Manual for LU Type 6.2. 


PROCESSIN 


G BY PS.SPS 


The component of LU presentation services 
that provides the syne potnt service is 
called PS.SPS, also called the syne point 
manager when all the resources used by a TP 
are at one LU, only one copy of PS.SPS is 
executed. Usually the situation 1s more com- 
plicated since every conversation allocated 
with the SYNC_LEVEL(SYNCPT) option connects 
two separate TPs, which cooperate to perform 
one or more distributed units of work. In 
the distributed cases, one TP is the first to 
issue the SYNCPT verb, and its local sync 
point manager becomes the sync point initi- 
ator for the current sync point, with respect 


TP 


Figure 5.3-2. 


to the sync point managers on the other ends 
of any conversation. These other sync point 
managers become agents with respect to the 
initiator, but may in turn become initiators 
with respect to additional, cascaded, syne 
point managers. 


The syne point managers maintain consistency 
of the changes to protected resources by the 
propagation throughout the network of these 
sync point commands: 


e Prepare--Solicits Request Commit. This 
command tells the agent to place its pro- 
tected resources in a state that allows 
them to be fully committed to the changes 
that have been accumulated during this 


TP 3 

TP 2 
TP 4 

1 TP 5 
TP 6 TP 7 


A Typical Syne Point Tree 


of work ID (LUWID) 
the 


LUW, but that also allows these changes 
to be reversed, or backed out. The 
choice to commit or back out is made by 
the initiator after interaction with all 
agents. 


© Request Commit--Solicits Committed. This 
command says that the issuer has suc- 
ceeded in preparing all of its protected 
resources. 


® Committed--Informs the soliciting syne 
point manager that all resources attached 
through this conversation are committed. 


® Forget--Informs the syne point manager 
that sent Committed that its log record 
for this LUW can be erased.* Forget also 
tells the initiating syne point manager 
that the sync point is complete and that 
control can be returned to the TP. 


® Backed Out--Informs the receiving syne 
point manager that the sending syne point 
manager has backed out the LUW. 


The SNA encoding for transmission of these 
commands are described in "Appendix H. FM 
Header and LU Services Commands" under pres- 


entation services (PS) headers for the first 


four, and FMH-7 sense data for Backed Out. 


The syne point managers keep records about LUWs on logs, held on nonvolatile storage by the 
log manager, so that LUWs can be kept consistent across failures of LUs. 
is comprised of three components: 
instance number, which is unique at the LU that creates it; and the sequence number, 
which is incremented by 1 following a successful syne point. 
correlator is used to further qualify LUWIDs. 


The logical unit 
the fully qualified LU network name; 


In addition, a conversation 


The LUWID is created by RM for a conversation 


whenever a conversation is allocated by a TP that does not already have an LUWID associated 


with it. 
by a TP that already has an LUWID. 


A TP already has an LUWID associated with it, if it was the subject of an Attach 
The LUWID and conversation correlator are carried in the 


FMH-5 (see "Appendix E. Request/Response Unit (RU) Formats" in Appendix E). 
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| PS .SPS 
ro : Initiator 
| TP | : 


SYNCPT 
> Prepare 
. > TAKE_SYNCPT * 
> 
SYNCPT 
< 
Request Commit 
< , 
Commi tted 
. > 
Forget 
< 
OK 
< 


NOTE: 


LUW STATES 


A distributed transaction program is a tree, 

with individual TPs as nodes on the tree, and 

conversations as branches. Distributed TPs 

support distributed LUNs, consisting of local 

LUNs at the individual TPs. The distributed 

LUW has a state made up of all the local LUW. 
states. For the distributed transaction pro- 

gram shown in Figure 5.3-2 on page 5.3-3, the 

distributed LUW state is a vector with seven 

components : 


LUW = [LUW1,LUW2, ... LUN7] 


where LUWi is the local LUW state fer IPi. 
The first TP to issue SYNCPT becomes the root 


of the tree for the global LUW that is ended | 


PS.SPS , 
Agent 
| 


by that verb. In the figure, the root, or 
initiator, is TP 1.) 7 


The sync point managers at each node of the 
tree cooperate to place all the LUW compo- 
nents into the same consistent state. They 
do this with four waves of syne point com- 
mands. 


The Prepare wave starts at the root and 
spreads down the tree. The Request Commit 
wave starts at the leaves (nodes without sub- 
ordinate nodes) and spreads up the tree to 
the root. The Committed wave returns down 
the tree, and the rorget wave flows up the 
tree to the root. Figure 5.3-3 shows these 
waves as they occur between the root and one 


of the nodes adjacent to the root. 


TAKE_SYNCPT is returned in the WHAT_RECEIVED field of verbs that can receive data. 


Figure 5.3-3. Basic Syne Point Flows 
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Figure 5.3-4. 
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Optimized Flow: No Resource Changed 
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Figure 5.3-5. Optimized Flow: Last Resource 


Figure 5.3-6. 


FLOW OPTIMIZATION 


Since wessage flows are costly, the sync 
point managers attempt to reduce the number 
of flows. Figure 5.3-4 on page 5.3-4 tllus- 
trates one such case: when a syne point man- 
ager agent determines that the state of the 
local LLW is reset, that is, no protected 
resources have been changed, it answers For- 
get to Prepare. Intermediate agents can 
reply Forget only if all the local LUWs in 
their entire subtree are reset. 


Figure 5.3-5 shows the other flow reduction 
that can be used. The initiator can pick one 
adjacent agent to receive Request Commit 
rather than Prepare. The Request Commit can 
be sent only after all the prepared agents 
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have sent Request Commit up their subtree to 
the initiator, making the selected agent the 
last agent. This last agent is then free to 
select one of its cascaded agents also to be 
last, and so on. 


Message flows are further reduced because the 
PS header that starts the sync point exchange 
indicates that one of three things should 
occur after the sync point message exchange 
is complete: the initiator is to be in send 
state, the initiator is to be in receive 
state, or the conversation is to be deallo- 
cated. This is shown in Figure 5.3-32 on 
page §.3-38 to Figure 5.3-36 on page 5.3-40. 
The first PS header sent has a modifier field 
that indicates the setting of the CD and CEB 
indicators of the RH that completes the syne 
point exchange. 


Syne Point Services for Local (Nonconversational) Resources, Such as Files 


§.3-5 


5.3-6 


SYNC POINT AND OTHER LU COMPONENTS 


The relationships among the transaction pro- 
gram, its resources, and the syne point man- 
ager are illustrated in Figure 5.3-6 through 
Figure 5.3-8. 


The following notes correspond to the numbers 
in Figure 5.3-6 on page 5.3-5. 


l. 


The transaction program issues a resource 
verb, which is passed, by the PS router, 
to the proper procedure to handle the 
local resource. See "Chapter 5.1. Pres- 
entation Services--Conversation Verbs" 
for details. 


The local resource is protected, and so 
it has a protection manager, which exam- 
ines the resource verb. If the resource 
is changed by the verb (e.g.», it 1s a 
Write of some kind), the protection man- 
ager writes a log record containing the 
before-change data.“ 


Eventually the transaction program issues 
SYNCPT or BACKOUT. The PS router invokes 


the sync point manager, which coordinates 
the action of all syne point managers 
involved in the distributed LUW. 


The sync point manager interacts with the 
protection manager for each protected 
resource, exchanging PS headers indicat- 
ing Prepare, Request Commit, Committed, 
and Forget to coordinate commitment, or 
an FMH-7 indicating Backed Out to coordi- 
nate backout of changes, either as 
requested by the TP, or as required by a 
resource failure. 


When all resources are prepared, the LUW 
is committed when the sync point manager 
writes Committed on the log, and forces 
the log.> The single force of the log is 
sufficient to commit the entire LUW 
because all local resources used by a 
single TP share a single log, which is 
also the log used by the TP's syne point 
manager. 


Recovery that uses the log records is 
discussed later in "Resynchronization 
Logic" on page 5.3-18. 


Logging before-change data is the technique suggested in the formal description. Other 
equivalent techniques are possible and permissible. 


Some writes to the log can be made to volatile log buffers. 
Other writes (called forced writes) to the log must 


failure of the LU, no damage results. 


If these are lost because of a 


be made to the nonvolatile log itself before the sync point protocol can proceed, if the LUW 


is to be kept synchronized even across LU failures. 


called forcing the log. 


This use of the nonvolatile log is 
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Figure 5.3-7. 


The following notes correspond to the numbers 
in Figure 5.3-7. 


1. The transaction program uses a conversa- 
i tion. The conversation resource (CR) 
protection manager is not sensitive to 

any of the conversation verbs. 


2. The CR protection manager does not write 
any log records. RM does write log 
records as part of ALLOCATE processing in 

j order to be able to re-create the 
resource control blocks (RCBs) and their 
relationship to transaction control 
blocks (TCBs) following an LU failure. 
See RCB on page A-7 for details of the 

! RCB and TCB. 


3. Eventually the transaction program issues 
SYNCPT or BACKOUT. The PS router invokes 
the sync point manager to do the coordi- 
nation. 


4. The syne point manager interacts with the 
protection manager for each protected 
conversation, exchanging Prepare, Request 

j Commit, Committed, and Forget PS headers 
to coordinate comnitment, or Backed Out 
to coordinate backout of changes, either 
as requested by the TP, or as required by 
a resource failure. 
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Protected conversations are treated some- 
what differently from protected local 
resources; this difference is driven by a 
lecal/nonlocal® indicator in the RCB. A 
Backed Out FMH-7 can be received frow 
nonlocal resources. Compare States GDS 
variables (also referred to as Compare 
States command or reply) can be exchanged 
with them to resynchronize following con- 
versation failures. 


The local protection manager for the con- 
versation communicates with tts remote 
partner by exchanging PS headers and the 
Backed Out FMH-7 sense data. The 
half-session has no Knowledge that a pro- 
tected conversation its assigned to it. 


The sync point manager has to do addi- 
tional writes to the log whenever nonlo- 
cal resources are pointed to by a TCB. 
Also, additional forces of the log are 
required. Finally, the sync point manag- 
er attempts  resynchronization by = an 
exchange of Compare States GDS variables 
with its partner sync point manager after 
resource failures. 


Local resources are those that share the sync point manager's log. 
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The following notes correspond to the rmambers 
in Figure 5.3-8. 


i. The transaction program allocates a 
resource that is located remotely. The 
local resource manager uses a conversa- 


tion to communicate to the remote 
resource. 
@. Neither the Ilocal-resource protection 


wanager nor the CR protection manager 
writes log records. The only logging is 
dene by RM in order to be able to 
re-create the resource RCBs and their 
relationship to TCBs. The ALLOCATE 
issued by the local resource manager is 
understood to be for a function shipping 
situation, so the conversation's RCB is 
chained under the local resource's RCB 
rather than being chained directly to the 
VOB. At the same time, the local 
resource’s RCB is marked nonlocal. 


%. Eventually the transaction program issues 
SYNCPT or BACKOUT. The PS router invokes 
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the syne point manager to do the coordi- 
nation. 


The sync point manager interacts with the 
protection manager for each protected 
resource, exchanging Prepare, Request 
Commit, Committed, and Forget PS headers 
to coordinate commitment, and Backed Out 
to coordinate backout of changes, either 
as requested by the TP, or as required by 
a resource failure. 


The nonlocal resources are treated the 


same as protected conversations: Backed 
Out can be received; Compare States GDS 
variables can be exchanged. 


The protection manager for the local 
resource, after dealing with local states 
(e.g. on a Prepare it may need to flush 
a local buffer), passes the PS headers 
that it receives from the sync point man- 
ager to the CR protection manager. 


e Manual for LU Type 6.2 


5. The syne point manager has to do addi- 
tional writes to the log whenever nonlo- 
cal resources are pointed to by a TCB. 
Also, additional forces of the log are 
required to handle the extra error states 
introduced by the existence of remote 
logs. Finally, the sync point manager 
attempts resynchronization via exchange 
of Compare States GDS variables with 
partner sync point managers after 
resource failures. 


SYNC POINT LOGIC 


A transaction program can issue a SYNCPT verb 
as ane initiator, or in reply to a 
WHAT_RECEIVED value of TAKE_SYNCPT, 
TAKE_SYNCPT_SEND, or TAKE_SYNCPT_DEALLOCATE 
on RECEIVE. After giving the TAKE_SYNCPT 
indication, the conversation resource rejects 
most verbs until SYNCPT, BACKOUT, or 
SEND_ERROR is issued. See SNA Transaction 
Programmer's Reference Manual for LU Type 6.2 
for details. 


PS.SPS processes the SYNCPT verb 
phases described below. 


in the 


CLASSIFICATION PHASE 


Since SYNCPT can be issued under many circum 
stances, PS.SPS begins by scanning the 
resources allocated to the transaction pro- 
gram in order to determine their states. 
Further PS.SPS processing varies according to 
the states of the local resources and TP: 


1. PREPARE RECEIVED state--Prepare was 
received from an initiating sync point 
manager. The local TP did not initiate 


sync pointing. PS.SPS prepares its local 
and down-tree protected resources and 
replies up-tree with Request Commit if 
preparation succeeds. If it fails, it 
replies Backed Out. 


2. REQUEST COMMIT RECEIVED state--Request 
Commit was received from an Initiating 
syne point manager. The local TP did not 
initiate sync pointing. Since the initi- 
ating PS.SPS has used an optimized flow, 
which it can do only for the last 
resource that it is attempting to coordi- 
nate, the local PS.SPS coordinates the 
commitment of its local and down-tree 
resources and replies Committed if com- 
mitment succeeds. If it fails, it 
replies Backed Out. 


3. SEND state--All protected conversations 
are verified to be in SEND state. Before 
issuing the SYNCPT verb, the transaction 
program puts all its protected resources 
into SEND state. If required, this can 
be done by issuing REQUEST_TO_SEND and 
waiting for the right to send. 


4G. Unprotected resource--Resource was allo- 
cated with SYNC_LEVEL(NONE | CONFIRM). 
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The resource 
SYNCPT verb. 


is not affected by the 


At the end of the scan, PS.SPS knows if a 
resource (1.e., the one in PREPARE RECEIVED 
state) must be sent Request Commit during its 
local coordination. Request Commit must be 
sent last, after all other resources have 
been prepared. If no last resource is iden- 
tified, a UPM is used to select one. The UPM 
can consider things like minimizing session 
flows (which leads to making a remote conver- 
sation last whenever possibie). It can also 
choose to prepare all resources, which allows 
all coordination to proceed in parallel, 
Since Prepares can be sent simultaneously to 
several resources. 


If any protected resources are in Receive 
state or more than one last resource is iden- 
tified, the sync point manager recognizes a 
state error and abnormally terminates the TP. 
Since any TP may be sync point tnitiator, the 
design of the distributed TPs must be such 
that only one TP at a time is the initiator. 
For example, TPa is in conversation with TPb 
and TPb has a cascaded conversation with TPc. 
If TPa and TPc both initiate sync point with 
TPh at the same time, it is an error in the 
design of the transaction program. The sync 
point service at TPb recognizes this error 
and returns BACKED_OUT to TPb. TPb then 
issues the BACKOUT verb. Otherwise, PS.SPS 
advances to the Prepare phase. 


PREPARE PHASE 


PS.SPS now issues Prepare to all not-last 
resources. When Request Commit has been 
received from all of them, the next phase is 
entered. Other replies to Prepare are dis- 
cussed in "Errors during Sync Point" on page 
5.3-15. If no not-last resources exist, this 
phase is skipped and PS.SPS proceeds directly 
to the Request Commit phase. 


REQUEST COMMIT PHASE 


After receiving Request Commit from all 
not-last resources, PS.SPS issues Request 
Commit to the last resource, and waits for a 
reply, thus entering the Committed phase. 


COMMITTED PHASE 


PS.SPS completes sync point processing after 
receiving Committed from the last resource by 
sending Committed to all not-last resources, 
thus entering the Forget phase. 


FORGET PHASE 


In the Forget phase, PS.SPS waits for Forgets 
from all the not-last resources. When all 


5.3-9 


Forgets have been received, PS.SPS gives the 
SYNCPT verb that was issued by the local TP a 
return code of OK. 
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ILLUSTRATIVE SYNC POINT FLOWS 


The following figures and comments illustrate 
the preceding discussion. 
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Figure 5.3-9. Illustrative Syne Point Flow: 


The following notes correspond to the numbers 
in Figure 5.3-9. 


1. The distributed LUW begins in RESET 
state. Any change to a local protected 
resource or receipt by PS of any message 
unit Cincluding the initial Attach) over 
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Agent 


General Case 
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The * indicates sending to, or receiving from, multiple agents. 


a protected conversation drives a local 
LUW from RESET to PGM PENDING. 


The initiating TP issues SYNCPT. PS.SPS 


logs all affected conversations except 
the last as [INITIATOR, SPM PENDING] 
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q 


Tha leg records are [state of 


while the last one is not logged yet.’ 
The log is forced once. PS.SPS sends 
Prepare to all but the last agent (here 
the * at the end of Prepare means all the 
agents, except possibly the last). 


Each agent PS.SPS returns to its trans- 
action program, a WHAT_RECEIVED value of 
TAKE_SYNCPT. All TPs agree by issuing 
SYNCPT. 


The agent PS.SPS logs [AGENT, SPM PEND- 
ING] for the conversation over which the 
Prepare is received. It logs [INITI- 
ATOR-CASCADE, SPM PENDING] for all the 
cascaded conversations, if any exist 
(there might only be local resources). 
The log is forced once if and only if any 
cascaded conversations exist. 


All cascaded agents agree to commit. 
PS.SPS places [AGENT, IN DOUBT] on the 
log and forces the log. 


All agents agree to commit. (INITIATOR, 
IN DOUBT] is placed on the log if and 


only if the last resource is being opti- 


mized with the last-resource sequence. 
If IN DOUBT is placed on the log, the log 
is forced and then Request Commit is sent 
to the last agent. 


The last agent replies Committed (Cif the 


optimized flow is being used for the last. 
[INITIATOR, COMMITTED] is logged 


agent). 
and the log is forced. 
to all agents 
last). 


Committed is sent 
(except the optimized 


8. 


10. 


li. 


synchronization Logic'’ 


An implied Forget is sent to the last 


cagent with the aid of RM and the session 


process. The implied Forget is the next 
normal-flow RU of any kind that flows 
from the initiator to the last agent. 
For instance, if the agent sent Committed 
as CEB, then the next RU wight be a (8B, 
Attach); or it might be a (BB, LUSTAT)3 
or BIS; or a data reply to a BB that came 
from the agent's half-session. Since the 


Committed can get lost, the agent retains 


the state of the LUN across session out- 
age. Since the implied Forget can get 
lost, and since the initiator may have 
erased its log, the agent carries a 
resyne responsibility for itself. Only 
in this way can it erase its log. "Re- 
on page 5.3-18 
describes resync in more detail. 


PS.SPS logs [Initiator-Cascade, Commi t- 
ted] for all cascade agents and forces 
the log. It then sends Cownitted to the 
cascaded agents. 


All cascaded agents return Forget. 
PS.SPS resets the LUW by erasing the log; 
then PS.SPS sends Forget to the initiator 


. and returns control to the agent TP. 


All agents return Forget. PS.SPS erases 
the log and returns control to the initi- 
ating TP. The log does not have to be 


-. forced before PS.SPS sends Forget, since 


any Forgets lost during a failure can be 


reconstructed by resynchronizing with 


cascaded agents. 


lecal PS.SPS relative to remote PS.SPS, state of local LUNI. 
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NOTE: The * indicates sending to, or receiving from, multiple agents. 


Figure 5.3-10. 


Illustrative Syne Point Flow: 


The following notes correspond to the numbers 
in Figure 5.3-10. 


1. 


The distributed LUN begins in RESET 
state. Any change to a local protected 
resource or receipt by PS of any message 
unit Cincluding the initial Attach) over 
@ protected conversation drives a local 
LUW from RESET to PGM PENDING. 


The initiating TP issues SYNCPT. PS.SPS 
logs the last conversation as (INITIATOR, 
IN DOUBT]. It forces the log and sends 
Request Commit. 


The agent PS.SPS presents TAKE_SYNCPT to 
the agent transaction program. The TP 
agrees by issuing SYNCPT. 


The agent PS.SPS logs [AGENT, SPM PEND- 
ING] for the conversation over which the 
Request Commit is received. It logs 
{INITIATOR-CASCADE, SPM PENDING] for all 
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Last-Resource Optimization 


the cascaded conversations, if any exist 
(there might be only local resources). 
It forces the log if and only if any cas- 
caded conversations exist. 


All cascaded agents agree to commit. The 
agent PS.SPS logs [INITIATOR—-CASCADE, 
COMMITTED] and forces the log again (Cin 
the example, the agent is not using the 
last-resource optimization on cascaded 
resources). Then it sends Committed to 
all cascaded agents. 


The agent PS.SPS waits for all cascaded 
agents to return Forget. This is done so 
that, in case of failures and resynchro- 
nization, it can return to the initiator 
an accurate report of any damage that may 
occur from heuristic decisions (discussed 
in "DEALLOCATE_ABEND_#" on page 5.3-15). 


All Forgets are returned. The subtree 
for which this PS.SPS is responsible is 
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COMMITTED. The agent PS.SPS returns Coa- 
mitted to the initiator, even if no 
dowm-tree resources were changed, and 
then returns control to its TP. 


The initiator sees the Committed. If 
there are no other participants, the ini- 
tiator erases the log for the LUW and 
returns OK to the initiating transaction 


while the Forgets from the not-last 
agents are collected. See Figure 5.3-9 
on page 5.3-11 for this type of sequence. 


Implied Forget is sent to the last agent 
with the aid of the session process. 
That is, any conversation data that flows 
on the half-session is treated as an 
implied Forget. This includes a BB that 
begins a new conversation shen Committed 
was sent with CEB. 


NOTE : 


Figure 5.3~-11. 


program. If there are other agents, [IN- 
ITIATOR, COMMITTED] is placed on the log 
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The * indicates sending to, or receiving from, multiple agents. 


Illustrative Syne Point Flow: 


No Resources Changed 
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The following notes correspond to the numbers 


in 


figure 
is requested, 
been altered during the LUW. 


The situation that the 
illustrates arises when a sync point 
but no remote resources have 
In this case, 


Figure 5.3-11. 


the Request Commit and Committed flows are 
not necessary and are omitted. 


1. 


The distributed LUW begins in RESET 
state. Any change to a local protected 
resource or receipt by PS of any message 
unit Cineluding the initial Attach) over 
a protected conversation drives a local 
LUN from RESET to PGM PENDING. 


The initiating TP issues SYNCPT. PS.SPS 
logs all affected conversations but the 
last as [INITIATOR, SPM PENDING], not 
legging the last one yet. It forces the 
log once, then sends Prepare to all but 
the last agent (represented by the * fol- 
lowing Prepare). 


3. 


The agent PS.SPS presents TAKE SYNCPT to 
the agent TP, which agrees to commit. 
The rest of this flow illustrates the 
processing performed by a single agent 
where no resources have been changed. 
The generalization to cascaded LUNs is 
straightforward. 


The agent PS.SPS sees (by receiving For- 
gets from the local resources) that no 
resources have been changed. It resets 
the LUW by erasing the log, sends Forget 
to the initiator, and returns control to 
the agent TP. ~ 


The agent returns Forget. The Request 
Commit and Committed flows were not 
needed; the initiator PS.SPS still proc- 
esses the flows from other conversations 
that may or may not require the addi- 
tional flows. 
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FORCING TH 


LOG 


PS.SPS needs to force the log only once when 
all resources are local, while it uses at 
least two forces of the log as the initiator 
(SPM PENDING and COMMITTED states) and may 
use an additional force (IN DOUBT state) if 
the last resource is flow optimized. 


PS.SPS uses at least one log force as the 
agent (IN DOUBT state), but if any cascaded 


ERRORS DURING SYNC POINT 


The preceding discussion assumed that sync 
point processing completed normally, without 
incident. This section shows how consistency 
can be maintained even when errors occur. 


The errors addressed are those caused by many 
transaction programs operating independently 
of each other, communicating only when 
required. With this independence, unexpected 
return codes can occur after any verb. As 
the issuer of internal verbs to the conversa- 
tion resource protection manager (PS.CRPM) in 
order to exchange sync point commands with 
partner sync point managers, PS.SPS has logic 
to deal with these return codes: 


®  PROG_ERROR_*, including SVC_ERROR_* 

¢ BACKED_OUT 

e DEALLOCATE_ABEND_* 

®  RESOURCE_FAILURE_* 

Because recovery from conversation failure 


can require that a session be reactivated, 
PS.SPS gives special consideration to the 
case where this cannot be accomplished in a 
timely manner. 


PROG_ERROR_* 


PS.SPS treats PROG_ERROR_* as BACKED_OUT. It 
is the using transaction program's responsi- 
bility to avoid this by correct transaction 
design. | 


BACKED_OUT 


BACKED_OUT is the return code given when the 
remote transaction program issues a BACKOUT 
verb. Unlike the case of FROG _ERROR_*, where 
the TP that issued SEND_ERROR gives the TP 
th... receives the PROG_ERROR_* an option, on 
BACKOUT the issuing TP expects the evatire 
distributed LUN to be backed out. The TP 
that receives BACKED_OUT therefore propagates 


the backout to all other resources by als 


issuing the BACKOUT verb. | 
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conversations exist for this LUW, the agent 
PS.SPS has to appear to the cascaded agents 
as if it were the initiator. Therefore, the 
middle agent has to force the log (SPM PEND- 
ING state) in order to reliably assume the 
resyne responsibility if it should terminate 
abnormally. The middle agents do not need to 
force the log to COMMITTED state since resyne 
will re-establish this state if it is lost. 


DEALLOCATE_ABEND_* 


PS.SPS may receive DEALLOCATE_ABEND_*. Since 
PS.SPS for the abnormally terminating TP will 
back out all of the TP's local resources, the 
local PS.SPS treats these return codes as 
BACKED_OUT. 


RESOURCE_FAILURE_*, RECOVERY, AND HEURISTIC 
DECISIONS 


Recovery from conversation failure depends 
upon the state of the conversation at the 
time of the outage: 


1. If the conversation is under the control 
of the sync point manager, it attempts to 
recover from the failure by exchanging 
Compare States GDS variables with the 
remote sync point manager as part of 
resync processing. PS.SPS does this by 
issuing ALLOCATE specifying the LU resyne 
service TP X‘'O6F2' as the transaction 
program. See "Resynchronization Logic" 
on page 5.3-18 for the logic that is exe- 


cuted during this resynchroni zation 
effort. 

If resynchronization succeeds, PS.SPS 
absorbs the RESOURCE_FAILURE_* return 


code and returns from the SYNCPT or BACK- 
OUT verb with the appropriate SYNCPT or 
BACKOUT return code. PS gives’ the 
RESOURCE_FAILURE_* return code to the TP 
on the next verb (other than SYNCPT and 
BACKOUT® ) issued against the failing 
conversation, inus making the sync point 
verb and the resource failure appear to 
have occurred in the reverse order. This 
is done for the convenience of the TP 
writer. A TP that is using protected 
resources can take advantage of this by 
issuing SYNCPT or BACKOUT whenever a con- 
versation failure return code is recog- 
nized. This gets the TP to a Known 


6 If SYNCPT and BACKOUT returned RESOURCE_FAILURE_* there would be no way to resynchronize 
short of an IPL to drive the resyne logic. 
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state: backed out to the last successful 
sync point call. Backed out state is 
arrived at when BACKOUT or SYNCPT is 
issued, after a resource failure, because 
a resyne occurs. In this case, resyne 
can only lead to backed out. The TP can 
then perform its own recovery logic from 
a known state, greatly simplifying the 
TP's recovery logic. 


Because a new session may not be imme- 
diately available, the syne point manager 
and the iock manager have a protocol 
boundary that provides a capability to 
free locks on resources that may be 
needed by other TPs. When the lock man- 
ager needs to release locks, PS.SPS uses 
| the guidance provided by the TP's entry 
in the transaction program list in RM; 
i the LU control operator, or a programmed 
i operator. The choices are either to hold 
the locks or to choose to do a partial 
commit or a partial backout of those 
resources with which communication has 
been maintained. The guidance (not shown 
in this book) indicates whether commit- 
ting, backing out, or holding the locks 
is to be performed when the TP fails and 
the lock manager needs to release locks. 
As PS.SPS makes this decision with only 
partial information, it is called a 
heuristic decision. 


| BACKOUT PROCESSING 

i 

i 

j 
When processing the BACKOUT verb, PS.SPS 
causes all protected resources in the LUW to 
be restored to their condition at the start 
of the LUW. The exception is that protected 
conversations are not deallocated, and the 


remote TPs that they started are not termi- 
nated by backout processing. 


Like SYNCPT, BACKOUT is propagated to all TPs 
associated with the LUN. Also like SYNCPT, 
BACKOUT propagation requires all transaction 
programs that share a distributed unit of 
work to participate by issuing verbs, i.@.; 
BACKOUT. 


When a transaction program is notified of a 
BACKOUT initiated by another transaction pro- 
gram, the remote BACKOUT is complete. That 


PS.SPS reports the resource state (which- 
ever is chosen, HEURISTIC COMMIT or 
HEURISTIC RESET) to the LU control opera- 
tor (since the heuristic decision may 
result in a loss of synchronization among 
the distributed resources that has to be 
repaired by operator action) and saves 
the state for comparison during resyn- 
chronization. The PS.SPS that is respon- 
sible for resynce continues = resyne 
attempts until resync completes. At this 
time, PS.SPS writes another message to 
the LU control operator and erases the 
LUW's log entries. 


2. If the conversation is not under the con- 
trol of the sync point manager, the 
responsibility for recovery is the trans- 
action program's. However, if syne point 
is in use, the TP can typically turn the 
recovery processing over to the sync 
point manager by using the SYNCPT or 
BACKOUT verb as soon as any desired proc- 
essing has been completed. Resources 
that are not protected are cleaned up 
according to application program logic. 
A failure by one TP or the other to 
return control to the sync point manager 
can lead to an extended holding of locks 
on shared resources. It may also lead to 
heuristic decisions if the locks have to 
be broken. 


is» the conversation resource that reports 
BACKED_OUT has already done so. The return 
code indicating this, BACKED_OUT, may be 
returned on several of the verbs. No backout 
of other resources in the local unit of work 
has been done. The TP must issue BACKOUT 
before it issues any other verb against pro- 
tected resources. 


Of particular interest is the case where 
BACKOUT is issued in the midst of SYNCPT 
processing. The locally issued BACKOUT takes 
precedence over the SYNCPT requested by the 
remote TP if the LUW stays intact. See Fig- 
ure 5.3-12 and Figure 5.3-13 for examples 
that illustrate how this is accomplished. 
For brevity, the Forget commands are not 
shown. 


5. 3-16 SNA Format and Pretocol Reference Manual for LU Type 6.2 


Hig 


Committed Sequence Backed Out Sequence 1 Backed Out Sequence 2 

1. A -> B — Prepare 1. A -> B — Prepare 1. A -> B — Prepare 

2. B-> C — Prepare 2. B -—> C — Prepare 2. B —> C — Prepare 

3. B-> D — Prepare 3. B-> D — Prepare 3. B —-> D — Prepare 

4. C —-> B — Request Commit 4. C -—> B — Request Commit 4. C -—> B — Request Commit 

5. D —> B — Request Commit 5. D —> B — Backed Out 5. D —> B — Request Commit 

6. B-> A — Request Commit 6. B -—> C — Backed Out 6. B-> A — Request Commit 

7. A -> B — Committed 7. B -—> A — Backed Out 7. A -> B — Backed Out 

8. B —-> C — Committed 8. B -—-> C — Backed Out 

9. B -> D — Committed 9. B -> D — Backed Out 
STATUS = Committed STATUS = Backed Out STATUS = Backed Out 


Figure 5.3-12. Back Out Example 1 


Committed Sequence Backed Out Sequence 1 Backed Out Sequence 2 

1. A -> B — Prepare 1. A —> B - Prepare 1. A -> B — Prepare 

2. A —> C — Prepare 2. A -> C — Prepare 2. A -> C — Prepare 

3. B—> A — Request Commit 3. B -—> A — Request Commit 3. B -> A — Request Commit 

4. C —> A — Request Commit 4. C -—> A — Backed Out 4. C —> A — Request Commit 

5. A-> D — Request Commit 5. A -> B — Backed Out 5. A —-> D — Request Commit 

6. D —-> A — Committed 6. A -> D — Backed Out 6. D —> A — Backed Out 

7. A-> B — Committed 7. A -> B — Backed Out 

8. A -> C — Committed 8. A -> C — Backed Out 
STATUS = Committed STATUS = Backed Out STATUS = Backed Out 


Figure 5.3-13. Back Out Example 2 
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Each implementation of the syne point option 
set makes available to transaction programs 
at least one protected resource that is fully 
reliable in that it is not subject to 
heuristic decisions. This can be done in a 
variety of ways; the simplest is to allow 
application designers to designate certain 


RESYNCHRONIZATION LOGIC 


5.3-18 


Resynchronization logic involves these steps: 


e If an IPL has occurred, RM retrieves log 
records from the log manager and recon- 
structs the protected TCBs and RCBs that 
were active at the time of the failure. 
It then causes PS.SPS to gain control on 
the reconstructed TCB. PS.SPS uses the 
log to restore its relevant states. For 
instance, it restores the initiator/agent 
state for each resource. PS.SPS also 
supplies log records to the protection 
managers for each resource so that they 
can back out their resources if this is 
required. 


e When PS.SPS finishes resynchronizing, RM 
deallocates the TCB. 


© If the resyne is occurring without an 
IPL, PS.SPS will return control to the TP 
or to the abnormal termination process- 
or, depending on the caller. The abnor- 
mal termination processor, of course, 
will deallocate all resources as needed. 


© Since it can happen that multiple conver- 
sations connect TCBs with the same LUWIDs 
in two separate LUs, resynchronization 
uses the the value in the Conversation 
Correlator field carried in Attach (see 
“Appendix H. FM Header and LU Services 
Commands") to uniquely identify the LUN 
whose states are to be compared. For 
example, this case occurs when TPa at LUa 
allocates a conversation with TPb at LUb. 
Then, as part of the same LUW, TPb allo- 
cates a conversation with TPe at LUa. 
The conversation correlator provides a 
way for PS.SPS at LUa to distinguish the 


resources as not subject to heuristic deci- 


sions. However the reliable resource is pro- 
vided, application designers can use data 
kept in the reliable resource to aid in 


recovery from any heuristic mismatches that 
may occur. 


part of the LUN that LUa initiated from 
the part that LUb initiated. The conver- 
sation correlator is unique in a network. 
To provide uniqueness, the fully quali- 
fied LU name of the LU that created the 
conversation correlator is concatenated 
to the conversation correlator when com- 
parisons are made. The fully qualified 
LU name of the partner LU is Known from 
the system definition of the PARTNER_LU 
data structure. 


The decision to initiate resyne by either end 
is depends upon the state of the unit of 
work. The following table reflects the 
action PS.SPS takes after a conversation 
failure or an IPL of the LU. 


UNIT-OF—-WORK STATE ACTION BY PS.SPS 
Cin local log) 


Not Found.......... No Action 

Agent, not last ... Wait for resyne 
Agent, last ....... Resyne after time-out 
Initiator ......... Initiate resyne 


VALIDATION OF LOG IDS 


The first level of resynchronization is the 
validation of the log IDs. PS.SPS accom- 
plishes this by exchanging Log ID GDS vari- 
ables. When this exchange validates the 
integrity of the LU pair's logs, PS.SPS 
exchanges Compare States. The following fig- 
ures illustrate this resyne logic. 
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(1) SYNCPT 


RECEIVE_AND_WAIT < 


Session Outage Notification 


ALLOCATE same LUWID as the I!'S that is being resynchronized 
SYNC_LEVEL(CCi.FLRM), 
TeNtX'O6F2') 1... 3 
BIND 
| > (optional ) 
Attach 
a a eS 
SEND_DATA Exchange Log Name, log status (warm), log name (log name) 
sips ei it ici lac isn ne tise ee as 
SEND_DATA Compare States command, CD 
> 


Exchange Log Name, log status (warm), log name (log name) 


(2) Compare States reply, CD 


RECEIVE_AND_WAIT < 


DEALLOCATE 
TYPECSYNC_LEVEL) LUSTAT(X'0006'), RQD2, CEB 
> 
(3) +DR2 
< 
Figure 5.3-14. Resyne after Conversation Failure 
The following notes correspond to the numbers LUWID carried 
in Figure 5.3-14. TCB. 
1. The TP issues SYNCPT or BACKOUT; giving 2. 
PS.SPS control. Conversation failure 


RECEIVE_AND_WAIT 
(2) 
RECEIVE_AND_WAIT 
SEND_DATA 


SEND_DATA 


RECEIVE_AND_WAIT 
(3) 
CONFIRMED 


in this Attach from the 


results from the session outage. PS.SPS 
detects this and begins resynchronization 
by issuing ALLOCATE specifying the resync 
transaction program, X'06F2', as the TPN. 
The optional BIND may flow between LUs as 
a result of RM logic; RM will send BIND 
to activate a nen session if an existing 
session is not available; PS.SPS does not 
know if it flows. PS.SPS retrieves the 
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PS.SPS validates the log name and then 
executes resynce logic. Each conversation 
to be resynchronized 1S processed in a 
separate resync conversation using a sep- 
arate copy of the resync TP. 


PS.SPS tells the log manager to erase the 
LUW's log records. The half-session 
sends an LUSTAT because there is no data 
to send. The LUSTAT carries the RH. 
PS.SPS is not aware of this detail. 
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(1) 


RECEIVE _AND_WAIT <————— ©. --- 


LU fails 
ALLOCATE same LUWID as the LUW that is being resynchronized 
SYNC_LEVEL( CONFIRM), 
TPN(X'O6F2') 1... 3 
: BIND 
> 
Attach 
a ee ee een ee a ee ee ee eae a eee NT, 
SEND_DATA Exchange Log Name, log status (warm), log name (log name) 
— $$. $$ > RECEIVE_AND_WAIT 
SEND_DATA Compare States command, CD (2) 


~~. wo. 


(2) Compare States reply, CUD 


> RECFEJVE_AND_HWAIY 


Exchange Log Name, log status (warm), i0g name (10g name) SEND_DATA 


SEND_DATA 


DEALLOCATE 
TYPE (SiNC_LEVEL ) LUSTAT(X'0006'), RQD2, CEB 
> RECEIVE_AND_WAIT 
(3) 
(3) +DR2 CONFIRMED 
< 


Figure 5.3-15. 
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Resyne after LU Failure 


The following notes correspond to the numbers 
in Figure 5.3-15. 


1. The LU fails. After the LU is IPLed, RM 
reads the syne point records from the 
log, rebuilds the TCB and RCBs, and gives 
PS.SPS control. After re-establishing 
the states of the local protected 
resources in cooperation with their pro- 
tection managers, PS.SPS proceeds to 
resync each LUW in a separate conversa- 
tion, since the reply can be delayed 
while cascaded resyne occurs. If all the 
resyne conversations are processed in 
parallel, multiple sessions will be 
used--up to one per LUW to be resynchro- 
nized. This can cause as many BINDs as 
LUNs that are in resynchronization. A 
UPM determines the degree of parallelism. 
The more parallelism, the more session 
resources will be used, but the resyne 
may complete faster. 


3. PS.SPS erases the log. 


2. PS.SPS validates the log name and then 
executes resyne logic. 


If a conversation 
or LU failure occurs during resynchroni- 
zation, PS.SPS repeats resynchronization 
until both logs are erased. 


SESSION! OUTAGE DURING ATTACH 


If session outage occurs, the Compare States 
command that is part of resyne can arrive 
ahead of the session outage notification. 
When this occurs and the last-resource opti- 
mization 1s being used, and if no special 
steps were taken, the result could be that 
one partner backs out and the other partner 


commits. The resolution of this race condi- 
tion is depicted in Figure 5.3-16 on page 
5.3-21. 
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ALLOCATE 
SEND_DATA ¥BB, Attach, data, Request Commit, CD 
SYNCPT 
SON SON 
eK, 
BB, Compare States(Session ID) 
UNBINO (cleanup) 
< 
Not Found 
< 
TES; 


PS .SPS(2) 


> (4) 
DEACTIVATE_SESSION 
TYPE( CLEANUP ) 
SESSION_ID(Session ID) 


> (purged) (5) 
> (purged) 


(6) 


This shows how the failure is prevented by deactivating the session prior to 
processing the Compare States command. 


PS.SPS(1) is the PS.SPS instance that is running on behalf of the application TP. 


PS.SPS(2) is the PS.SPS instance that is processing the Compare States command. 


It is 


using a different session from that used by the application TP. 


Internal flows are not show. 


Figure 5.3-16. 


The comments below correspond to the numbers 


1. A transaction 1s allocated with a sync 
level of sync point. 


2. Data is sent and a sync point (Cin this 
case, for an optimized last resource) is 
requested. 


3. After the data and Request Commit are 
sent, a session outage occurs. Both 
sides of the conversation are informed of 
the outage. 


4&4. When the sync point manager receives the 
outage indication, it sends a Compare 
States command (Exchange Log Name also 
flows but it is not shown in the dia- 
gram). This flows on a different session 
from the transaction program data. This 
session can use any mode. However, the 
performance characteristics of the mode 
should be gaod enough to avoid undue 
delays in resynchronization. As a result 
of using a different session, the Compare 
States command can arrive ahead of the TP 
data. 


To resolve this race condition, the 
receiving sync point manager, PS.SPS(2), 
issues a DEACTIVATE_SESSION TYPE( CLEANUP) 
whenever Compare States is received. The 
Session Instance Identifier field of the 
Compare States command has the session 
identifier, to allow the sync point man- 
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Presentation 


Avoiding Failure Resulting from an Attach-SON Race 


ager to deactivate the affected session. 
When the session deactivation is com- 
plete, any Attaches that are in transit 
are discarded and RM purges any records 
received from that half-session. Then 
the Compare States processing can pro- 
ceed. If the Attach has been processed 
and the attached TP executed before the 
deactivation is complete, a log entry for 
the LUW will be found. If the Attach is 
discarded, no log entry will be found. 
In either case, both data bases will 
remain synchronized. 


5. Depending upon shen the Attach and SON 
arrive, either path control, RM or LNS 
purges them because the session has been 


deactivated. 
6. The receiving syne potnt = manager, 
PS.SPS(2), checks the log for amareness 


of the LUN for which the Compare States 


was sent. Since the Attach has not 
arrived yet, or it was purged, no log 
entry exists. The reply to Compare 


States is therefore Not Found. 


It is possible that the incoming Attach has 
been processed and the PS process for the 
application TP was created, but the TP has 
never been dispatched when the Compare States 
arrives. In this case, the Attach arrives 
ahead of the Compare States, but as a result 
of timing conditions in the node, the Compare 
States TP (shown above as PS.SP5(2)) executes 
before the attached application TP. Then,» 
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Figure 5. 3-17. 


before the application TP runs and the LUW is 
logged, the half-session is deactivated 
because of the Compare States processing. 
When the DEACTIVATE_SESSION processing is 
completed, PS.SP5(2) checks the log to find 
the state of the LUW. The LUW is not logged 
yet, so the reply to the Compare States is 
Not Found. In order to avoid having the 
application TP execute later and commit the 
LUN, the syne point manager that is running 
on behalf of an application TP checks that 
the LUW was not previously backed out, 
because of a session deactivation, before it 
commits. This is accomplished by having RM 
inform the syne point manager that = the 
half-session it is using was deactivated. 
The sync point manager cannot perform a Com- 
mit if it is informed of a session deacti- 
vation. 


LOST SYNC POINT MESSAGES 


The logic for resyne is summarized in Fig- 
ure 5.3-21 on page 5.3-26 through Fig- 
ure 5.3-25 on page 5.3-30. This logic is 


derived from Figure 5.3-19 on page 5.3-24, — 


SEND_ERROR 


Prepare 


nn, fon 
(purged )< : 
Prepare 
(purged )< 
> 


which shows the sync point messages that can 
be lost because of session outage, as viewed 
by the initiator. For example, when a Pre- 
pare is lost because of SON, the state of the. 
LUW at the sender of the Prepare (the initi- | 
ator), is either SPM PENDING or HEURISTIC . 
RESET; the state of the LUW at the receiver . 
(the agent) is either RESET or PGM PENDING. | 
In the case when SEND_ERROR and Prepare are 
lost from one TP and Prepare is lost from the 
partner, the state of LUW on either side of 


the conversation is SPM PENDING or HEURISTIC 


RESET. Given this, it is possible to con-_ 
Struct the tables that guide the resynchroni- 
zation actions that the sync point managers 
must take. 


Prepare vs. Prepare races (when both sides 
issue Prepare, and the flows cross), Prepare 
vs. Request Commit races, and Request Commit 
vs. Request Commit races also can occur as a 
result of races between session outage 
notification and SEND_ERRORs. 


An example is shown in Figure 5.3-17. 


SENO_ERROR and Prepare vs. Prepare Race during Session Outage 


5.3-22 


When one TP issues SENO_ERROR followed by 
SYNCPT and messages are lost because of ses- 
sion outage, it is possible that both part- 
ners are the sync point initiator. In this 
case, each reports its state on the Compare 
States reply as if it were an agent. 


The one exception to this rule is in the case 
shown in Figure 5.3-18 on page 5.3-23. In 
this case, when resynchronizing, the original 
sender of Prepare (sync point services[1]) 


recognizes that the partner is resynchroniz- 
ing (following SON, the partner (sync point 
services[2]) sent a Compare States command 
with a state indicator of IN DOUBT). The 
sender of Prepare then replies with a RESET 
state indicator on the Compare States reply. 


The details of resync, based on the state of 
the LUW is shown in the matrix itn Fig- 
ure 5.3-19 on page 5.3~24 and the logic 
depicted in Figure 5.3-23 and Figure 5.3-24. 
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sync point 


TP services 
(1) 


SYNCPT 


syne point 


services TP 
(2) 


SEND_ERRAR 
Prepare 


< 
(purged )< 
Request Commit SYNCPT 


(purged )< 


New conversation Compare States request 


Figure 5.3-18. 


(state indicator = RESET) 


ae: 


Compare States request New conversation 
(state indicator = IN DOUBT) 
< , 


Compare States reply 
(state indicator = RESET) 


Compare States reply 
(state indicator = RESET) 
< 


SEND_ERROR and Request Commit vs. Prepare Race during Session Outage 
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Syne Point Message Lost} Initiator's State When Agent's State 
| By Session Outage It Initiates Resync When Resync Occurs 
SPM PENDING | RESET | 


Prepare [3] 
HEURISTIC RESET [1] PGM PENDING [2] 
Prepare vs. SEND_ERROR | SPM PENDING | | SPM PENDING | 
HEURISTIC RESET [1] HEURISTIC RESET [1] 


and Prepare [51 

SPM PENOING | IN bouBT | 
HEURISTIS RESET [1] HEURISTIC RESET [4] | 
HEURISTIC COMMITTED [4] 


[Prepare vs. SEND_ERROR 
and Request 
Commit(last) [51] 


SPM PENDING | . 
| Request Commit HEURISTIC RESET [1] 


Committed COMMITTED 


| IN DOUBT | 
HEURISTIC RESET [4] | 
HEURISTIC COMMITTED [4] 


IN DOUBT | 
HEURISTIC RESET [4] 
HEURISTIC COMMITTED [4] 


| Request Commi t( last) IN DOUBT | RESET | 
(3) HEURISTIC RESET [4) | PGM PENDING [2] 
HEURISTIC COMMITTED [4] 


IN DOUBT | 
HEURISTIC RESET [4] | 
HEURISTIC COMMITTED [4] 


Request Commit( last) 
vs. SEND_ERROR and 
Prepare [5] 


SPM PENDING | 
HEURISTIC RESET [1] 


IN DOUBT | 
HEURISTIC RESET [4] | 
HEURISTIC COMMITTED [4] 


Request Commit(last) 
vs. SENO_ERROR and 
Request Commit( last) 


IN DOUBT | 
HEURISTIC RESET (4) | 
HEURISTIC COMMITTED [4] 


IN DOUBT | 
HEURISTIC RESET [4] | 
[HEURISTIC COMMITTED [4] 


Committed( last) COMMITTED 


Notes: 
1. The LUW has been backed out as a result of a heuristic request from 
the lock manager. The initiator still owes resync to the agents. 
2. The PGM PENDING state is never visible during resync, since it 
is converted to RESET. 
3. These rows assume that no Prepare vs. Prepare type races have occurred. 
4. Either HEURISTIC RESET or HEURISTIC COMMITTED can occur from IN DOUBT. 
5. The agent issues SEND_ERROR and a sync point message, making the 
agent also an initiator for this race. 


Figure 5.3-19. Lost Sync Point Messages: Initiator's View 
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Lost Message 


Implied Forget 


Last Agent's State when 
it sends Compare States 
command 


COMMITTED [Note] 


State of receiver of 
Compare States 
command 


RESET | COMMITTED | 
HEURISTIC COMMITTED 


Note: 
log. 


The last agent does not have to send this Compare States command unless it needs to erase its 


The last agent does have to remember the COMMITTED state if it does not receive Forget, either 
implied or as part of the initiator's resyne or following its own resync. 
5.3-30 for further details.) It 


(See Figure 5.3-25 on page 


is not possible to eliminate entirely this responsibility of the 
last agent without coupling the sync point resyne to a single session instance. 


If the sync point 


resyne were restricted to a single session instance, session data on that session could be treated as 
an Implied Forget. 


Figure 5.3-20. 


Lost Messages for Sync Point: 


RESYNCHRONIZATION ACTION 


Figure 5.3-21 on page 5.3-26 through Fig- 
ure 5.3-25 on page 5.3-30 show the indicated 
States that the sync point manager is either 
sending or receiving in the Compare States 
command, in relation to the action taken. 
The logic depicted in these diagrams is the 
logic needed to implement resynchronization 
when an IPL has taken place or after an LU or 
a session fails. 


The top left-hand corner of the tables indi- 
cates the role the sync point manager has in 
the syne point exchange. In Figure 5.3-21 on 
page 5.3-26, Figure 5.3-23 on page 5.3-28, 
and Figure 5.3-25 on page 5.3-30 the 
left-hand column shows the state indication 
that is sent on the Compare States command. 
The top row shows the state that is indicated 
in the Compare States reply. In Fig- 
ure 5.3-22 on page 5.3-27 and Figure 5.3-24 
on page 5.3-29, the left-hand column shows 
the state that is indicated in the Compare 
States command. The top row indicates the 
state of the LUN at the receiver; this state 
is indicated in the returned Compare States 
reply. 


The matrix entry for the column-row pair 
indicates the action to be taken based on the 
pair of state indications exchanged. The 
action to be taken includes changing the 
state of the LUW at the LU and/or sending a 
message to the control operator. (See "Re- 
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Last Agent's View 


synchronization Operator Messages" on page 
5.3-30 for a description of the messages sent 
to the LU control operator.) For example, in 
Figure 5.3-21 on page 5.3-26, if the initi- 
ator finds the state of an LUW to be IN DOUBT 
on its log, it sends a Compare States command 
to the last agent, with the state indicator 
in the command set to IN DOUBT. If the ini- 
tiator receives a Compare States reply with 
the state indicator set to RESET, it backs 
out the LUW. If the Compare States reply 
indicates COMMITTED, it commits the LUN. If 
the Compare States reply indicates HEURISTIC 
MIXED, it either commits or resets the LUN, 
based on a heuristic decision. The heuristic 
decision taken depends on the transaction 
program's defined characteristics. When the 
heuristic decision is taken, the LU control 
operator receives message 3. 


Figure 5.3-21 on page 5.3-26 and Fig- 
ure 5.3-22 on page 5.3-27 show the actions 
when resynchronizing with the last agent. 
The last agent must be resynchronized before 
any not-last agents are resynchronized 
because the state indication the last agent 
returns on the Compare States command con- 
trols the state indication sent to = any 
not-last agents. When a Request Commit is 
sent to the last agent, the state of the LUW 
at the initiator with respect to the last 
agent is IN DOUBT. No other resynchroniza- 
tion is possible until it is Known whether 
the state of the LUW at the last agent is 
RESET or COMMITTED. 
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\ INITIATOR 


RESET | HEURISTIC 


\ RECEIVES. COMAITTED HEURISTIC | HEURISTIC 
N LOG ENTRY RESET [3] | COMMITTED 
\ NOT FOUND 
INITIATORN 
SENDS 


RESET [3] 
SPM PENDING 
(3) 2 
IN DOUBT 
3 , 
COMMITTED 
(3) 4 
foc mee 


HEURISTIC 
COMMITTED 


HEURISTIC 
MIXED [3] 7 


Notes: 


1. All intersections with dots should not occur. States 1, 2, 4, and 7 are not. possible at the 
initiator. Message 4 is generated for the control operator if indications of states 2, 3, 5, or 
6 are returned by the last agent on the Compare States reply. 


2. The heuristic direction is taken from the TP definition table. The TP definition table is 
created when the TP is defined to the LU. The HR (HEURISTIC RESET) or HC (HEURISTIC COMMITTED) 
action applies to local resources and cascaded resources. HEURISTIC MIXED (HM) state is reported 
to the resyne initiator on the Compare States reply. In the case where the resyne initiator was 
a cascaded agent, HM is reported to the sync point initiator in a PS header (Heuristic Mixed) 

3. These state indications should never occur. 


Figure 5.3-21. Resynchronization Action: At Initiator, When Resynchronizing with the Last Agent 
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\ LAST 


\ AGENT RESET | IN DOUBT COMMITTED | HEURISTIC | HEURISTIC | HEURISTIC 
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CURISTIC 
RESET MSG 3 [4] 
5 
MSG 3 [4] 


HEURISTIC 
MIXED [5] 7 


Notes: 


1. 


5. 


All intersections with dots should not occur. States 1, 2, 4, and 7 are not possible at the 
initiator. Message 4 is generated if indications of states 2, 3, 5, or 6 are returned by the 
last agent. | | 


If resync occurs while the last agent is still in SPM PENDING or IN DOUBT state, the agent defers 
sending the reply until it completes its cascaded protocol, which may include resynchronization 
with cascaded agents. Eventually the last agent's state will resolve to RESET, COMMITTED, or 
HEURISTIC MIXED. The HEURISTIC MIXED state is reported when SON occurs on sessions with at least 
two cascaded agents and the control operator at one of the LUs causes the LUW to be put into a 
HEURISTIC RESET state, while the operator at the other LU causes the LUW to be put into a 
HEURISTIC COMMIT state. If there are no cascaded resources, the last agent changes the state of 
the LUW to reflect the state reported on the Compare States request. 


In these cases, the agent takes no action, except to erase its log (if the log entry was found) 
upon the completion of the resyne flows. The end of the resyne flows is defined by receipt of 
LUSTAT(X'0006'), RQD2, CEB from the initiator, or receipt of +RSP(LUSTAT) from the agent. See 
Figure 5.3-14 on page 5.3-19 and Figure 5.3-15 on page 5.3-20 for more details. 


A HEURISTIC MIXED situation (described in Note 2) has been detected and is reported to the resyne 
initiator on the Compare States reply. The HEURISTIC MIXED state indicator is not propagated to 
the cascaded agents. See Figure 5.3-23 on page 5.3-28 for this case. 


These state indications should never occur. 


Figure 5.3-22. Resynchronization Action: At Last Agent, When Resynchronizing with the Initiator 
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IN DOUBT [6] 3 
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Notes: 


1. 


2. 


6. 


Fi 


All intersections with dots should not occur. States 2; 3, and 7 are not possible at the 
initiator. Message 4 is generated if an indication of state 2 or 3 is returned by the agent. 


If resyne occurs while the not-last agent is still in SPM PENDING or IN DOUBT state, the agent 
defers sending the reply until it completes its cascaded protocol, ichich may include 
resynchronization with cascaded agents. Eventually the not-last agent's state will resolve to 
RESET, COMMITTED, or HEURISTIC MIXED. The HEURISTIC MIXED state is reported when SON occurs on 
sessions with at least two cascaded agents and the control operator at one of the LUs causes the 
LUW to be put into a HEURISTIC RESET state, while the operator at the other LU causes the LUW to 
be put into a HEURISTIC COMMIT state. If there are no cascaded resources, the last agent enanges 
the state of the LUN to reflect the state reported on the Compare States request. 


In these cases, the agent takes no action, excep: to erase its log (if the log entry was found) 
upon the completion of the resync flows. 


In all the HEURISTIC MIXED (HM) cases displayed in this matrix, while HEURISTIC MIXED is reported 
as a return code on the SYNCPT verb, HM is not propagated to agents. Rather, they are told the 
initial state of the initiator so that Message 3 is not issued for those agents that are 
synchronized with the initiator. This is illustrated by the following case: the initiator of 
resynchronization reports COMMITTED on the Compare States command, the agent has three protected 
cascaded conversations. The agent finds SPM PENDING on its log, so it = initiates 
resynchronization with its cascaded agents. One of the cascaded agents reports HEURISTIC 
COMMITTED and the other reports HEURISTIC RESET on the Compare States reply. Rather than send a 
Compare States command indicating HEURISTIC MIXED to the third protected conversation, COMMITTED 
is reported. 


When the initiator is in SPM PENDING state, it has resyne responsibility. However, it reports 
its state as RESET on the Compare States command. The SPM PENDING state indicates that a resync 
is expected. If the state is actually RESET, no resync is needed. 


These state indications should never occur. 


gure 5.3-23. Resynchronization Action: At Initiator, When Resynchronizing with the Not-Last Agent 
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\ *LAST 
\ AGENT RESET SPM IN DOUBT COMMITTED | HEURISTIC | HEURISTIC | HEURISTIC 
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AGENT \ 
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IN DOUBT 
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HEURISTIC 
RESET 


HEURISTIC 
COMMITTED 


4 
G 


HEURISTIC 
MIXED [4] 7 


1. All intersections with dots should not occur. States 2, 3, and 7 are not possible at the | 
initiator. Message 4 is generated if they are received. 


2. If resyne occurs while the agent is still in SPM PENDING or IN DOUBT state, the agent defers 
sending the reply until it completes its cascaded protocol, which may include resynchronization 
with cascaded agents. Eventually the not-last agent's state will resolve from SPM PENDING to 
RESET or HEURISTIC MIXED; or IN DOUBT will resolve to RESET, COMMITTED, or HEURISTIC MIXED. If 
there are no cascaded resources, the last agent changes the state of the LUN to reflect the state 
reported on the Compare States request. 


3. In these cases, the agent takes no action, except to erase its log upon the completion of the 
resync flows. 


4. These state indications should never occur. 


Figure 5.3-24. Resynchronization Action: At Not-Last Agent, When Resynchronizing with the Initiator 
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Notes: 
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2. 


Figure 5.3-25. 


5.3-30 


The last agent erases its log upon receipt of the initiator's state indication. 


If the initiator is in any state other than RESET, both the last agent and the initiator ignore 
the state exchange that started from the last agent. It was started, at the last agent, by the 
sending of a Compare States command. 


perform the actual resynchronization. 


The last agent actually finds COMMITTED on its log. 
initiator has already sent the implied Forget, but the implied Forget was lost. 
initiator has no log record that 
After a period of time, 
responsibility. 
RESET, 


if the 
It sends RESET. 
it means there has been a resync race. 


resync is forthcoming. 


Resynchronization Action: 
RESYNCHRONIZATION OPERATOR MESSAGES 


The sync point manager issues several mes- 
sages to the LU control operator. Messages 
can be sent to the operator at the following 
times: following session outage, during the 
log name exchange, and during the resync 
exchange. The parameters shown in parenthe- 
sis (such as TPN, for transaction program 
name) are passed in the message. In the wmes- 
sages that follow, reference is made to a 
‘waiting unit of work’. <A waiting unit of 
work jis an LUW for which resynchronization is 
necessary. Until the resynchronization is 
complete, resources may be locked and una-~ 
vailable for other computations. The order 
that the messages may occur in are shown in 
Figure 5.3-26 on page 5.3-31. 


® MSG 1: A heuristic decision has been 
wade for transaction program name (TPN), 
process ID (PID), at time (TIME), and 
legical unit of work ID (LUWID). As a 
result, resources in LUs (LU nmame-1, LU 
name-2, ... » LU name-X) may be in incon- 
sistent states with respect to the local 
resource states. 


Operator Action: Take user-defined 
action, if any» to protect data integrity 
until the local and remote data can be 
synchronized. 


* MSG 2: Resources in LUs (LU name-l, ... 
» LU name-X), previously reported to be 
exposed to state inconsistency with 
respect to local resources for trans~ 
action program name (TPN), process ID 
(PID), at time (TIME), logical unit of 
work ID (LUWID), have been found to be 
synchronized. 


In this case, 


The state indication exchange started by the initiator will 


it is possible that the 
As a result, the 


indicates that the tnitiator is responsible for the resync. 
initiator has not attempted to resync, the last agent takes 
If the initiator replies with any state indication other than 


The initiator has resyne responsibility and the 


Resync from Last Agent 


Operator Action: Reverse the 
user-defined action taken when MSG 1 was 
acted upon. 


MSG 3: Resources in LUs (LU namel, ... » 
LU nameX), previously reported to be 
exposed to inconsistency with respect to 
local resources for transaction program 
name (TPN), process ID (PID), at tiwe 
(TIME), logical unit of work ID (LUWID), 
have been found to be out of synchroniza- 
tion. 


Operator Action: Take user-defined 
action to resynchronize the local and 
remote resources. 


MSG 4: Protocol failure in resynchroni- 
zation logic during attempted resynchro- 
nization of transaction program name 
(7PN), process ID (PID), at time (TIME), 
logical unit of work ID (LUNID), conver- 
sation correlator (CIO). The local state 
was state (state name), the remote state 
was state (state name). 


Operator Action: Make inquiries to 
determine the state of the resources. 
Take user-defined action to resynchronize 
the resources. Submit APAR report. 


MSG 5: Session failure (with LU name-i,» 
mode name-j) at time (TIME), has resulted 
in a waiting unit of work for transaction 
program name (TPN), process ID (PID), 
with logical unit of work ID (LUWID) and 
conversation correlator (CID). This LUN 
is coupled to other LUs (LU name-m,..., 
LU name-n). 


Operator Action: Reactivate the session 
as soon as possible. 
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A 


Figure 5.3-26. The Sequence of LU Control Operator Messages Generated by Sync Point 
Resynchroni zation 
* MSG 6: The waiting unit of work identi- * MSG 10: LU (LU name) has returned an 


fied by transaction program name (TPN), 
process ID (PID), and logical unit of 
work ID (LUWID), reported at time (TIME), 
is being committed. 

Operator Action: none. 

MSG 7: The waiting unit of work identi- 
fied by transaction program name (TPN), 
process ID (PID), and logical wit of 
work ID (LUWID), reported at time (TIME), 
is being backed out. 


Operator Action: none. 


MSG 8: Resources in LUs (LU name-l, ...> 
LU) name-X), previously reported to be 
waiting for  resynchronization with 


respect to local resources for trans- 
action program name (TPN), process ID 
(PID), at time (TIME), logical unit of 
work ID (LUWID), have been found to be 
out of synchronization. 


Operator Action: Take user-defined 
action to resynchronize the local and 
remote resources. 


MSG 9: The logical unit of work identi- 
fied by transaction program name (TPN), 
process ID (PID), at time (TIME), logical 
unit of work ID (LUWID), has been waiting 
for HHH hours and MMM minutes. Locks 
held by this  resynchronization are 
enqueued by NN transactions. 


Operator Action: If desired, abnormally 
terminate the PID specified process. 
This will release locks and may result in 
heuristic mismatches when resynchroniza- 
tion does complete. 
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abnormal reply to the Exchange Log Name 


command. This LU has” detected a 
warm/cold mismatch, or a log name mis- 
match. 


Operator Action: Coordinate activation 
with the operator at the other LU. It 
may be necessary to abnormally terminate 
processes for some waiting units of work. 


MSG 11: A cold start has been attempted 
by LU (LU name), but the local LU has 
logical units of work that are awaiting 
resynchronization from the previous acti- 
vation. 


Operator Action: Coordinate activation 
with the operator at the other LU. It 
may be necessary to abnormally terminate 
processes for the waiting units of work. 


MSG 12: LU (LU name) does not have the 
Same memory as does the local LU of the 
previous activation between then. 


Operator Action: Coordinate activation 
with the operator at the other LU. It 
may be necessary to abnormally terminate 
processes for the waiting units of work. 


ORDER OF RESYNCHRONIZATION 


When = a 


distributed unit of work fails 


because of a session or LU failure, more than 
one resynchronization exchange may be needed 


before resynchronization is complete. 
ure 5.3-27 on page 5.3-32 


Fig- 
illustrates what 


can happen. 
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Figure 


5 .3-32 


Prepare 
< 


Request Commit 
> 


(B Fails) 


Request Commit 


Resyne flows 


< 


Resync flows 
<> 


§.3-27. Cascaded Resynchronization Example 


The rule illustrated in the figure is the 
following: The initiator resolves in-doubt 
resources before it resynchronizes with the 
other resources involved in the logical unit 
of work. One result can be that some partic- 
ipants in the distributed LUW will make 
heuristic decisions. 


ERRORS AND FAILURES DURING RESYNCHRONIZATION 


Errors and additional failures can occur dur- 
ing attempted resynchronization. Repeated 
conversation failures are handled by the 
resynchronization logic, since log records 
are not erased until after the state indi- 
cations have been = exchanged; see Fig- 
ure 5.3-14 on page 5.3-19 and Figure 5.3-15 
on page 5.3-20 for examples. Errors that 
occur while the sync point manager has con- 
trol, such as completion of the receive timer 
that is started when resynchronization 
begins, are mapped into conversation fail- 
ures, created by UNBIND, thereby falling back 
into an error recovery loop = (described 
below). 


The conversation failures, created by UNBIND, 
to recover from errors detected while the 
sync point manager has control are 
UNBIND(X'FE08640002' | X'FE08640001') depend- 
ing on the error—timer or logic error, 
respectively—rather than DEALLOCATE(ABEND), 
since the latter is not guaranteed to work 
under double failures (the receiver of DEAL- 
LOCATE has to continue to issue RECEIVE in 
order for it to work). 


PROCESSING 


The following two figures illustrate the 
processing of log names so that log mis- 


The error recovery process is described as a 
loop because it iterates until one of the 
loop exit conditions is satisfied. The error 
recovery loop has two exits: Either (1) the 
resync completes, or (2) the control opera- 
tor, after being informed that the resyne 
attempt has been going on for a long time 
(the resynce timer completes), decides to 
abnormally terminate processes that are hold- 
ing locks for this LUW rather than continue 
with the syne point manager resync attempts. 
The cleanup transaction will erase the log 
record after writing suitable messages to the 
error log. It may additionally force 
(unilaterally change, without agreement among 


partners ) the states of any pending 
resources, to HEURISTIC RESET or HEURISTIC 
COMMITTED, in the same way that heuristic 


decisions may force states. 


RESET STATE AND ERASING OF LOG RECORDS 


Reset state of the LUW (equivalent to unit of 
work backed out) is denoted by the absence of 
a log record. 


The initiator's side can erase its log when 
all Forget flows have been completed, 
because, at this point, it is Known that 


resyne will never be required. Therefore the 
question of ambiguity of no record found nev- 
er arises. 


The slaves erase their logs before sending 
Forget, so that a subsequent failure that 
results in the loss of the Forget will result 
in a resyne that finds no log record. 


matches do not occur. <A log mismatch occurs 
if the LU control operator mounts the wrong 


The ambiguity is that not finding a log record could mean that the LUW has either not been 


logged yet (not started), or is committed (completely finished). 
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sync-point-log tape or 


instructs the LU to 


use the wrong log-dataset; or the LU IPLs and 


no log exists (this 
start). 


is referred to as a cold 
When this happens, the sync-point 


(1) 


(2) 
(3) 


(4) 


Figure 


LU IPLs Cold 


5. 3-28. 


« 


e 


ALLOCATE new LUWID, 
SYNC_LEVEL( CONFIRM), 
TPN(X'O6F2') <.. 

BIND 
Attach 


Exchange Log Name, log status(cold), CD 


Exchange Log Name, log status(cold), RQD2, CEB 
< 


+DR2 


Cold Start of an LU 


The following notes correspond to the numbers 
in Figure 5.3-28. 


1 


The LU IPLs cold, that is, with a new log 
tape or new log dataset. No resynec 
attempt occurs, since the log is empty. 
If the name of the LU's log is changed, a 
cold IPL is required. 


PS.SPS 1s given control before any con- 
versations with SYNC_LEVEL(SYNCPT) are 
allocated in order to exchange log names 
with PS.SPS in the partner LU. The sync 
point manager needs to Know the partner's 
log name so log mismatches can be 
detected during resynchronization. 
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| log is not available for resyne processing. 
| The Exchange Log Name command is sent before 
| the Compare States command, to detect a log 
| mismatch. 


nm 
e 
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The resyne TP, X'06F2‘, accepts the cold 
log name and returns its own LU‘s log 
name. Message 11 might also be returned 
on an error reply, as shown in Fig- 
ure 5.3-29 on page 5.3-34. 


Upon logging the log name of the partner 
PS.SPS, PS.SPS tells RM © that 
SYNC_LEVEL(SYNCPT) conversations can now 
be allocated to the partner LU. 


The partner PS.SPS similarly informs its 
RM. Race conditions can cause this 
transaction to be executed twice, once in 
each direction. 


5.3-33 


C1) 


(2) 


(3) 


Figure 5.3-29. 


5. 3-34 


LU IPLs Warm, with wrong log (log can be a disk aataset or tape volume) 


i. 


| 
| 
| 
| 
| 
| 
| 
| 
| 2. 
| 

| 

| 


e 


atLOCATE 


SYNC_LEVEL( CONFIRM), 
TPN(X'O6F2') ... 


BIND 


Attach 


Exchange Log Name, log status (warm), log name (log name) 


Compare States, CD 


Exchange Log Name(error reply), RQE1, CEB 
< 


Log Name Mismatch during Resync 


The following notes correspond to the numbers 
in Figure 5.3-29. 


The LU IPLs warm, but the wrong log vol- 
ume is active. However, RM and PS.SPS do 
not Know this at first, and proceed with 
resyne processing. 


The partner PS.SPS detects the mismatch 


of log names, notifies its control opera-. 


tor with Message 12, and returns an error 
reply. 


ve 
e 


same LUWID as the LUW that is being resynchronized, 


PS.SPS sees the error reply and notifies 
its control operator of the mismatch with 
Message 10. Conversations bith 
SYNC_LEVEL(SYNCPT) cannot be allocated 
between these LUs until the mismatch has 
been fixed. Perhaps the correct volume 
can be activated; or the operator can use 
a cold IPL, although this may damage the 


consistency of protected resources. 
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PROCEDURES USED BY SY 


& 


POINT 


| 


PS_SPS 


FUNCTION: 


To coordinate syne point processing, as described in this chapter. 
are not formally specified. 


Details 


The syne point service is made up of a con- 
trolling subcomponent (PS.SPS) that deter- 
mines when presentation services headers 
should be sent, and a subcomponent (in con- 
versation resources protection manager 
[PS.CRPMJ]) that builds and sends the sync 
point headers. The subcomponents that build 
and send syne point headers are: 


1. PREPARE 
2. REQUEST_COMMIT 
3. COMMITTED 

G. FORGET 

5. HEURISTIC_MIXED 


The calling tree to show the relation of the 
components of sync point services is shosm in 
Figure 5.3-30 on page 5.3-36. 


A high-level overview of these subcomponents 
is described below. 


PREPARE 


The presentation services header contains a 
field (i.e., Syne Point Control Modifier) by 
which the receiver is requested to take a 
specific action upon completion of the sync 
point flows. This is done because the initi- 
ator issues SYNCPT when it is in either SEND 
state or DEFER state (see FSM_CONVERSATION on 
page 5.1-63). DEFER state is reached two 
ways: by issuing PREPARE_TO_RECEIVE or DEAL- 
LOCATE with TYPE(SYNC_LEVEL) when the syne 
level is SYNCPT. At the completion of the 
syne point flow, the sender of the last sync 
point command has send control; however, the 
TP may not need send control. Therefore, on 
the first command of the sequence, the Sync 
Point Control Modifier field of the PS header 
indicates the side of the conversation that 
is to have send control, or deallocation 
responsibility, after the last sync point 
command is sent. The Syne Point Control Mod- 
ifier can be set to the following values: 


Chapter 5.3. 


Presentation 


Request RECEIVE: The sync point initi- 
ator requests to be in RECEIVE state upon 
completion of the sync point flow. 


Request DEALLOCATE: The sync point ini- 
tiator requests that a DEALLOCATE be 
issued upon completion of the sync point 
flow. 


Request SEND: The syne point tnitiator 
requests to be in SEND state upon cor- 
pletion of the sync point flow. 


When PREPARE is issued, the CD and CEB indi- 
cators in PS's send buffer (see Chapter 5.1) 
may be in one of three combinations of set- 
tings: 


1. -CD and -CEB—neither PREPARE_TO_RECEIVE 
nor DEALLOCATE has been issued. 


2. CD and ~CEB—PREPARE_TO_RECEIVE has been 
issued. 


3. -CD and CEB—DEALLOCATE has been issued. 


If in state 1 (-CD and 
(Prepare) with modifier Request SEND is 
placed in the send buffer. The RQE1, CD; and 
EC indicators are turned on and the send 
buffer is sent to DFC. The Prepare then 
requires a reply. The reply will be etther a 
PS header (Request Commit Forget) or a 
-RSP. If a PS header ts received, PREPARE 
subcomponent returns with a REQUEST_COMMIT or 
FORGET return code. It can also return 
RESOURCE FAILURE Cit is not a 
resource-specific verb). If a PS header, 
~RSP(0846), or resource failure is not pres- 
ent, a fatal error has occurred and the ses- 
Sion is deactivated (using X'FE' reason code 
and appropriate UNBIND sense code). If a 
~RSP(0846), is received, the next data to 
arrive on the session is an FMH-7 and the 
return code is set according to the FMH-7 
sense data. 


“CEB), a PS header 


If in state 2 (CD and -CEB), a PS header 
(Prepare) with modifier Request RECEIVE is 
placed in the send buffer. The RQE1, CD, and 
EC indicators are turned on and the send 
buffer contents are transmitted to DFC. The 
PREPARE subcomponent then requires a reply. 
A PS header indicates a successful Prepare} 
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SYNC POINT MANAGER | 
(PS.SPS) 


CONVERSATION RESOURCE! 
PROTECTION MANAGER. 
— (PS.CREM) 


TT PREPARE| 


Note: 


Figure 5.3-30. 


5.3-36 


REQUEST FORGET 
COMMIT 


COMMITTED 


HEURISTIC 
MIXED 


| RESOURCES MANAGER 
(RM) 


RESYNC TP 
>} (X'O6F2") 


All relationships are via Call and Return except for the RESYNC TP, 
which is invoked as a remote service transaction program. 


Sync Point Services Calling Tree 


the return code is set accordingly. If a 
~RSP(0846) is received, the next data to 
arrive on the session is an FMH-7 and the 
return code is set accordingly. 


in state 3 (-CD and CEB), a PS header 
(Prepare) with modifier Request DEALLOCATE is 
bel in the send buffer. The RQE1, CD, and 
indicators are turned on and the send 
oer contents are transmitted to DFC. The 
PREPARE subcomponent then requires a reply. 
ae PS header indicates a successful Prepare} 
return code is set. If a -RS5P(0846) is 
Sere fae the next data to arrive on the ses- 
sion is an FMH-7 and the return code is set 
-accordingly. 


REQUEST_COMMIT 


As for Prepare, PS's send buffer may be in 
the same three states when Request Commit is 
sent. Additional information is also know. 
PS.SPS and PS.CRPM know whether or not the 
current Request Commit is being sent in reply 
to a Prepare. PS.CRPM uses the information 
to build the PS header. PS.SPS knows whether 
or not changes have occurred in = other 
resources for this LUW. 

When Prepare has not been received, these 
cases apply: 

1. When in state 1 (-CD and ~-CEB), the 
REQUEST_COMMIT subcomponent causes PS 
header (Request Commit, Request SEND) to 
be transmitted and waits for the reply. 
If Committed is received, REQUEST_COMMIT 
completes normally; however, if a 
~RSP(0846) is received, REQUEST_COMMIT 
processing waits for the FMH-7 and com- 
pletes with the appropriate return code. 
Session outage is indicated in the return 
code for REQUEST _ COMMIT as resource fail- 
ure. 


2. When in state 2 (CD and -CEB), the 
REQUEST_COMMIT subcomponent causes a PS 


header (Request Commit, Request RECEIVE) | 
to be sent. The reply will be either | 


Committed, SON, or a ~-RSP(0846) and 
FMH-7. The appropriate return code is 
set. 

3. When in state 3 (~CD and CEB), the 


REQUEST_COMMIT subcomponent causes a PS 
header (Request Commit, Request DEALLO- 
CATE) to be sent. The COMMITTED, SON, or. 
~RSP(0846) and FMH-7 reply sets the 
return code. 


When Prepare has been received, one of these 
cases applies (PS.SPS chooses); 


1. Changes have occurred in local or cas- 
caded resources. PS header (Request Cow- 
mit, Request SEND) is sent and the return 
code set according to the reply. 

2. No changes have occurred in either local 
or cascaded resources. The syne point 
manager does not send Request Commit} 
Forget is sent next. 

COMMITTED 

Committed is sent by PS.SPS as a reply to 

Request Commit. Committed is sent with RQEL, 

CD. No Syne Point Control Modifier is sent. 


If Committed is sent from the last resource, 
CD and CEB are set by PS.CRPM as spacified in 
Sync Point Control Modifier from the previous 
Request Commit. 


FORGET 


Unlike the case for the PREPARE and 
REQUEST_COMMIT subcomponents, the send buffer 
is in a Known state when Committed and Forget 
are sent. The FORGET subcomponent uses the 
information passed on the Syne Point Control 
Modifier field of Prepare to leave the con- 
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versation in the state desired by the trans- 
action that initiated SYNCPT. 


HEURISTIC_MIXED 


As in the case for FORGET, the send buffer is 
in a Known state when Heuristic Mixed is 
sent. The HEURISTIC_MIXED subcomponent 
builds and sends the PS header(Heuristic 
Mixed) using the information passed on the 
Sync Point Control Modifier field of the Pre- 
pare to leave the conversation in the state 
desired by the transaction that initiated 
SYNCPT. 


The Heuristic Mixed PS header is sent when a 
sync point agent discovers that two or more 


SESSION FLOWS CREATED BY SYNC POINT 


The following illustrates the flows that can 
be generated by SYNCPT: 
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cascaded agents have gotten out of sync after 
a failure and resync. This is illustrated in 
Figure 5.3-31 on page 5.3-38. In this dia- 
gram, conversation or session failures at TPb 
with TPce and TPd can lead to a heuristic 
decision at TPe that conflicts with the 
heuristic decision that 1s made at TPd. This 
can be avoided with properly defined failure 
recovery procedures for the LU control opera- 
tor. However, if heuristic damage occurs, it 
is discovered when TPb resyncs with TPc and 
TPd. Because no failure has occurred between 
TPb and TPa, no resyne occurs on that conver- 
sation. The Heuristic Mixed PS header is 
used to inform the sync point initiator, TPa,» 
that a heuristic decision has caused damage 
in the distributed LUW. 


5.3-37 


SYNCPT flow TPe - 
> (cascaded agent) 
SON followed by resync 

> 


TPa SYNCPT flow TPb 
(sync point <———————————> = (syne point TPd 
initiator) ‘ agent ) SYNCPT flow (cascaded agent) 
. & | {C pnseeneennencnsennnnenetneensinnnnensnnennsnnannsenennnannnnemes 2 


SON followed by resync 
> 


PS Header(Heuristic Mixed) 
1 seasecoeeneeseoneconastonsmmneaneeass eat Sdurnc ASR necoUSSctessaent AEA SS cSRSRaC ROS 


Figure 5.3-31. Heuristic Mixed in Reply to Syne Point Flow 


TP(1) | om a TP(2) 


_ SEND_DATA 
PREPARE_TO_RECEIVE 
SYNCPT 
| RECEIVE AND WAIT 
data, Request Commit(Request RECEIVE), RQE1, CD WHAT _RECEIVED=DATA 
> 
WHAT _RECEIVED=DATA 
RECEIVE AND WAIT 
WHAT_RECEIVED=TAKE_SYNCPT 
Committed, BC, -EC, -CD SYNCPT 
erent attri temaeenanenseeen it RC=0K 
(LUW STATE is COMMITTED) 
SEND_DATA 
SYNCPT 
a : RECEIVE AND WAIT 
data, Request Commit(Request SEND), R@E1, CD — WHAT_RECEIVEB=DATA 
: > 
RECEIVE, AND_WAIT 
WHAT _RECEIVED=TAKE_SYNCPT 
Committed, RQE1, CD SYNCPT 
<— : RC=O0K 
(LUN STATE is COMMITTED) 
SEND_DATA 
DEALLOCATE 
SYNCPT 


RECEIVE_AND_WAIT 
data, Request Comait(Request DEALLOCATE), RQE1, CD WHAT_RECEIVED=DATA 

> | | 

RECEIVE_AND_WAIT 

WHAT_RECEIVED=TAKE_SYNCPT 
Committed, RQE1, CEB SYNCPT 
<—nceeneemarennereeeetestteeateteern ratte ee ean eterna eetcrenereenteeeecenctn RC=O0K 
7 (LUN STATE is COMMITTED) 


Figure 5.3-32. Verb Sequences and Sync Point Flows to the Last Agent, Which Has No Cascaded 
Resources 
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TP(1) TP(2) 


‘ RECEIVE 
SEND_DATA ncenenrentnst et NT RC=OK WHAT_RECEIVED=DATA 
3 ° RECEIVE 
: ; RC-OK WHAT_RECEIVED=DATA 
SEND_DATA data, Prepare(Request SEND), RQE1, CD RECEIVE 
SYNCPT > RC=OK WHAT_RECEIVED=TAKE_SYNCPT 
SYNCPT 


Forget, RQE1, CD 
————— RC=OK (LUW STATE is COMMITTED) 
RC=OK (LUW STATE is COMMITTED) 


Figure 5.3-33. Syne Point with No Resources Changed: The Request SEND on the Prepare is a command 
to send CD on the return flow. The transaction program is not given a chance to send 
any data or to influence the conversation states (other than to terminate 
abnormally). This Request SEND is not the RH CD indicator but is in the PS header. 


TPO1) TP(2) 


° RECEIVE 
SEND_DATA Sree > RC=OK WHAT_RECEIVED=DATA 
. ° RECEIVE 


e 


‘é RC=OK WHAT_RECEIVED=DATA 
data, Prepare(Request SEND), RQE1, CD RECEIVE 


SYNCPT —_————— OOOO———iéRCC=OK «-WHAT_RECEIVED=TAKE_SYNCPT 
Request Commit, RQE1, CD SYNCPT 
< 
Committed, RQE1, CD 
: > 
Forget, RQE1, CD 
ee = REOAOK (LUN STATE 1S COMMITTED) 
RC=OK (LUW STATE is COMMITTED) 
SEND_DATA 
. Data 
; > 
RECEIVE 


Figure 5.3-34. Syne Point with Changes to Protected Resources, Request SEND: In this flow, the 
Prepare requests that the CD be returned (Request SEND) on the Forget. 
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TP(1) | TP(2) 


. RECEIVE | 
SEND_DATA ernment ei RC=OK WHAT_RECEIVED=DATA 
: . RECEIVE 
‘. . RC=OK WHAT_RECEIVED=DATA 
PREPARE_TO_RECEIVE Data, Prepare(Request RECEIVE), RQE1, CD RECEIVE 
SYNCPT ——— cerca RC=0K 


WHAT_RECEIVED=TAKE_SYNCPT 
Request Commit, RQE1, CD 


< SYNCPT 
Committed, RQE1, CD 
> 
Forget, BC, ~EC 
rr een remceunatrrmmenaaatinimtenaat een ne RC=OK | 
RC=OK (LUW STATE is COMMITTED) (LUW STATE is COMMITTED) 
RECEIVE 
data RC=SEND 
a SE a a eee SEND_DATA 


Figure 5.3-35. Syne Point with Changes to Protected resources, Request RECEIVE: The Request RECEIVE 


in Prepare indicates that the flow is to be reversed. The Forget is flushed to let 
locks be released. It is not necessary to flush the Forget if the TP is sure to 
generate application data right away. 


TP(1) | TP(2) | 


; RECEIVE 
SEND_DATA ———————————e——————————— RC=OK WHAT_RECEIVED=DATA 
° F RECEIVE 
° ‘ RC=OK WHAT_RECEIVED=DATA 
DEALLOCATE data, Prepare(Request DEALLOCATE), RQE1, CD RECEIVE 
SYNCPT LL cercaraeemenenee RC=OK WHAT_RECEIVED=TAKE_SYNCPT 
Request Commit, RQE1, CD SYNCPT 
Ere eeernesenemmenee enema verte PEER AA A ee RA i tr PA AD ncn TNE es SACS 
Committed, RQE1, CD 
> RC=OK (LUW STATE is COMMITTED) 
RECEIVE 


RC=DEALLOCATE_NORMAL 
Forget, CEB, RQEl 
(Creer cc nner A ACRE TE ST DEALLOCATE 
local deallocation 
local deallocation 


RC=OK (LUW STATE is COMMITTED) : 


Figure 5.3-36. Syne Point with Changes to Protected Resources, Request DEALLOCATE: The Request 


5 ® 3-40 


DEALLOCATE in the PS header (Prepare) is a command to send CEB on the return flow. 
The transaction program is not given a chance to send any data or to influence the 
conversation state if the syne point completes normally. If BACKOUT or a negative 
response is received, the transaction program is not deallocated and the TP may Issue 
BACKOUT. 
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Figure 5.3-37. 


SESSION FLOWS CREATED BY ERRORS DURING SYNC 
POINT 


All base error flows may occur. These 
include application errors, local resource 
failures, program failures, session failures, 
conversation failures, and LU failures. See 
Chapter 2 for an explanation of the types of 
errors. Additionally, BACKOUT can be issued. 
This verb causes flows the same as SEND_ERROR 
(i.@., -RSP(0846) followed by FMH-7) except 


the FMH-7 is limited to carrying a sense code 
of X'0824' (Sync Point Manager Abort). BACK- 
OUT may be issued whenever a SEND_ERROR can 
be issued (i.e., it is independent of the 
send/receive state). 


BACKOUT 


The BACKOUT verb results 
shown in Figure 5.3-37. 


in the sequence 


Do until RC=OK|RESOURCE_FAILURE_*|BACKED_OUT|DEALLOCATE_* 
Issue SEND_ERROR with a sense code of X'0824'. 
Issue a CONFIRM verb (Backout flows RQD2|3). 


If send control was at the other end at the last sync point 


Issue PREPARE _TO_RECEIVE (FLUSH). 


BACKOUT Logic 


This has the advantage of propagating the 
backout even if the partner transaction has 
issued SEND_ERROR. It also handles send and 
receive state variations. 


The expansion showm above places responsibil- 
ities on the transaction programs: for 
instance, if entered while the partner has 
the CD bit and before the first RU of the 
chain arrives, it can hang in the SEND_ERROR 
for a long time. This is because the 
SEND_ERROR doesn't cause a -RSP to flow until 
a chain arrives. Transaction programs that 
issue BACKOUT must take the potential delay 
into account. It is the transaction pro- 
gram's responsibility to make sure that the 
delay has no undesirable results. 
BACKOUT process takes too long to complete, 
the session can be abnormally terminated. 
The LUW state will be repaired by resync 
processing. 


Abnormal termination after a BACKOUT verb 


results in several flows, but this is accept- 
able, since it is an error case. 
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Transaction programs that are cooperating 
with each other need to obey a discipline in 
issuing SYNCPT. A TP must be coded to issue 
SYNCPT when its partner TP expects a syne 
point request. However, because the CD bit 
is» in effect, a protected variable (i.e., it 
flows in the Syne Point Control Modifier 
field of the PS header and the syne point 
manager is responsible for maintaining the 
conversation in the proper state with respect 
to the CD bit) the TPs do not need to obey a 
convention for BACKOUT. BACKOUT may be 
issued in SEND, DEFER, RECEIVE, CONFIRM, SYNC 
POINT, or BACKED-OUT state. The SEND state 
is restored to the transaction that onned it 
at the completion of the last successful 


If the SYNCPT. For BACKOUT prior to the first 
SYNCPT call; the CD bit is restored to the 
Attach sender. 
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CHAPTER 5.4. 


PRESENTATION SERVICES--CONTROL-OPERAT 


INTRODUCTION 


CONCEPTS 


This chapter presents an overview of LU serv- 
ices for the LU control operator, and in par- 


ticular describes those services contained in 


the presentation services components of the 
LU and in LU service transaction programs. 


FUNCTION SUMMARY 


The control operator is represented to the LU 
by a control-operator transaction programs 
which invokes operator functions by issuing 
LU-def ined control-operator verbs. The 
relationship between the control-operator 
transaction program and the control operator 
is implementation-defined and is not deter- 
mined by SNA. Throughout this chapter, the 


terms control-operator and control-operator 
transaction program are used synonymously. 


The control-operator transaction program dif- 
fers from application transaction programs in 
its focus on control-operator concerns and 
its privileged access to the control-operator 
verbs. 


The functions available to the control oper- 
ator and the control-operator verbs that 
invoke them are described in SNA Transaction 


Programmer's Reference Manual for LU Type 
6.2. That book is a prerequisite to this 
chapter. 


The control operator describes and controls 
the availability of certain resources. The 


particular functions and corresponding 
control-operator verbs are: 
To describe the network resources 


accessed by the local LU, such as trans- 
action programs, partner LUs, and mode 
names. The relevant verbs are: 


AND TERMS 


This section discribes some of the concepts 
and terms used throughout this chapter. 
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- DEFINE 
- DISPLAY 


e To control the number of sessions between 
the LU and its partners. The relevant 
verbs are: 


~ INITIALIZE _SESSION_LIMIT 
—  RESET_SESSION_LIMIT 

~ CHANGE_SESSION_LIMIT 

~ ACTIVATE SESSION 

—  DEACTIVATE_SESSION 


® To invoke local processing on behalf of a 
control-operator verb issued at a remote 
LU. The relevant verb is: 


- PROCESS_SESSION_LIMIT (This verb is 
not available to the local operator, 
but is issued from within the LU.) 


STRUCTURE SUMMARY 


This chapter describes two LU components for 
control-operator functions: presentation 
services for the control operator (PS.COPR), 
a component of presentation services, and the 


CNOS service transaction program (CNOS serv- 


ice TP). It also describes the functional 
relationship of these components to the 
installation- or implementation-defined 


control-operator transaction program, to the 
LU resources manager (RM-~-see Chapter 3), to 
presentation services for conversations 
(PS.CONV--see Chapter 5.0 and Chapter 5.1), 
and to half-sessions (HS--see "Chapter 6.0. 
Half-Session"). 


Figure 5.4-1 on page 5.4-2 shows the struc- 


tural relationship of these components (see 


Chapter 2 for the complete structure of the 
LU). 


OPERATOR 


The control-operator transaction program is 
an implementation-defined transaction program 
that interacts with presentation services on 
behalf of, or in lieu of, a human operator. 


§.4-]1 


Note: 


Figure 5.4-1. 
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in this chapter. 


Control-Operator Components in Relation to Other Components of the LU 


5.4-2 


The control-operator transaction program 
interacts with presentation services by issu- 
ing control-operator verbs to control the LU 
or to control the interactions of the LU with. 
a partner LU. 


A control-operator verb is a privileged verb 
that may be issued by the control-operator 
transaction program to convey the operator's 
request to the internal components of the LU. 
Control-operator verbs are described in SNA 
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Iransaction Programmer's Reference Manual for 
LU Type 6.2. 


SCOPE OF CONTROL-OPERATOR FUNCTIONS 


LU control-operator-verb functions vary in 
scope. 


Control-operator local functions affect only 
that LU whose control operator issues the 
control-operator verb, or they affect a ses- 
sion with another LU but take effect without 
the concurrent participation of a 
control-operator transaction program at the 
other LU. These functions include describing 
LU-accessed resources, regulating the number 
of sessions with single-session LUs, and 
activating and deactivating specific ses- 
sions. 


Control-operator distributed functions affect 
the relationship between the LU at which the 
control-operator verb is issued (called the 
source LU) and another LU with which it 
shares one or more sessions (called the tar- 
get LU). The functions take effect only with 
the cooperation of transaction programs 
representing the control operators at the two 
LUs. These functions involve primarily regu- 
lating the number of parallel sessions with 
other LUs» including orderly increase from no 
sessions and decrease to no sessions; they 


are called change-number-of-sessions (CNOS) 


functions. 


A control-operator verb for distributed func- 
tions may be issued at either LU. Thus, the 
roles of source LU and target LU are relative 
to a particular verb issuance: a particular 
LU may be source LU for one issuance and tar- 
get LU for another. 


LU-ACCESSED NETWORK RESOURCES 


The control operator describes to the local 
LU those network resources accessed from the 


local LU (LU-accessed network resources). 


The following resources are described. 
® The local LU itself 


® A gontrol point e.g.» an SSCP, that pro- 
vides session services during session 
initiation 


¢ Transaction programs available for exe- 
cution at this LU 


* Partner LUs: The remote LUs with which 
this LU can have sessions 


* Modes: defined sets of characteristics 
for sessions with particular partner LUs 
(One or more modes are defined for each 
potential partner LU.) 


The control operator also controls the number 
and availability of the following resources: 


®¢ Sessions with particular partner LUs. 


Each LU resource is identified to the opera- 
tor either implicitly or by a resource key 
such as a transaction program nawe, a partner 
LU name, a mode name, or a session identifi- 
er. 


Each LU resource is described by the LU defi- 
nition that characterizes the way the LU can 
use it. For example, these include trans- 
action program characteristics such as avail- 
ability status and optional functions 
supported; LU capabilities such as parallel 
sessions; mode name attributes such as ses- 
sion limits, RU size bounds » and 
cryptography; and control point capabilities 
such as INIT (logon) formats supported. 


SESSION CHARACTERISTICS 
Session Identification 


Most control-operator verbs do not specify a 
specific session, but specify only the part- 
ner LU and mode name for the session; the 
implementation selects the particular ses- 
Sion. Some verbs, however, can reference a 
specific session by specifying an 
implementation-supplied unique session ID. 


Single- ys. P 


rallel-Sassions 


An LU can be characterized by the number of 
sessions it allows with other = LUs. A 
Ssingle-session LU can have only one LU-LU 
session at a time; (it can have successive 
sessions with different partner LUs selected 
from aesgroup of LUs Known to it). A 
parallel-session LU can have one or more con- 
currently active sessions with each of one or 
more LUs, subject to session limits discussed 
below. No middle capability exists, i.e.» no 
LU supports concurrent sessions to multiple 
single-session LUs without also supporting 
multiple concurrent sessions (or parallel 
sessions) with any other parallel-session LU. 


The term paralle}] session denotes any session 
between a pair of parallel-session LUs, even 
if only one such session is currently active. 
This contrasts with the term single session, 
which denotes a session between a pair of 
single-session LUs er between a 
single-session LU and a parallel-session LU. 
A parallel session--even a solitary parallel 
session--uses protocols different from those 
used on a single session. 


Contention Polarity | 


Sessions are also characterized by their con- 
tention polarity. This determines which of 
the two LUs has the right to control use of 
the session. If two LUs attempt to initiate 
a conversation on the same session simul tane- 


ously, the LU that is contention winner for 
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that session will succeed and the other; the 
contention loser, will fail. 


When used in reference to sessions, these 
terms are relative to the perspective of one 
of the LUs: a session for which an LU is the 
contention winner is called a 
contention-winner session from its perspec- 
tive, but it Is a contention-loser session 
from the perspective of the partner LU. 
Unless otherwise specified, the perspective 
used in this chapter is that of the LU at 
which a relevant control-operator verb is 
issued. 


SESSION LIMITS AND COUNTS 


The number of active sessions between two LUs 
fluctuates as a result of transaction program 
demand and explicit operator action. The 
number of sessions active at any given time 
is called the session count. 


The maximum number of sessions” allowed 
between LUs is set dynamically by the LU 


operators. This number is called a session 
limit. Several session limits may be speci- 


fied by the operator. 


The total LU-LU session limit is the maximum 
number of LU-LU sessions allowed by the local 
LU. If this limit is 1, the LU is a 
single-session LU; if it is greater than 1, 
the LU is a parallel-session LU. This limit 
regulates the total LU-LU session count. 


The operator can regulate the number of ses- 
sions between the LU and a particular partner 
LU, and hence the number of transactions that 
can be active concurrently using that pair of 
LUs. 


The (LU,;mode) session limit specifies the 
currently allowed maximum number of sessions 
with a specific partner LU using a specific 
mode name. This limits the corresponding 
(LU,mode) session count, i.e., the number of 
currently active sessions with that partner 
LU using that mode name. One such limit and 
count exist for each mode name that is 
defined for each potential partner LU. 


In this chapter, unless otherwise specified, 
the unqualified terms "session Limit” and 
“session count" refer to the (LU,mode) ses- 
sion limit and count, respectively. 


For parallel-session connections, other lim- 
its regulate the (LU,mode) session count 
within the (LU,mode) session limit. 


The operator can assure that each J. can 
allocate a minimum share of the concurrent 
conversations by setting limits on session 
contention polarities. 


The local-LU minimum contention-winner Limit 
is the minimum number of sessions with a par- 
ticular (LU,mode) pair for which “he local LU 
is allowed to be the contention winner; the 
partner-LU minimum contention-winner Limit is 


the minimum number of sessions with that 
(LU,;mode) pair for which the partner LU is 
allowed to be the contention-winner. When 
activating a session, each LU selects a 
contention-polarity for the session that is 
consistent with these limits, i.e., it does 
not encroach on the partner's allowed con- 
tention winner sessions. 


The operator can specify that a certain num- 
ber of sessions be activated whenever the 
relevant limits allow, without waiting for 
explicit requests for each session. 


The automatic-activation limit is the maximum 
number of sessions that the local LU may 
activate in the absence of explicit requests 
from transaction programs or the operator. 


SESSION BRINGUP AND TAKEDOWN 


Phases 


The following four phases of session bringup 
and takedown activities exist, although some 
phases are omitted in some circumstances. 


Session-limit initialization and reset con- 


sists of issuing control-operator verbs to 
specify the number of sessions the LU can 
have with a given partner, and to specify 
conditions for their activation and deacti- 
vation. 


Session initiation and termination consists 


of control-point activity that mediates 
requests for session activation and deacti- 
vation, such as issuing INITEATE (INIT_SELF) 
and CONTROL INITIATE (CINIT) or TERMINATE 
(TERM_SELF) RUs. 


Session shutdown consists of the LU activity 


to terminate conversation activity (brackets) 
on the session by issuing BRACKET INITIATION 
STOPPED (BIS) RUs. 


Session activation and deactivation consists 


of exchanging the BIND or UNBIND request and 
response RUs between the LUs. 


Control-Operator Functions 


The operator can cause an orderly deacti- 
vation of sessions between a pair of LUs by 
specifying that the (LU,mode) session limits 
be reset to 0. 


The operator can also specify whether to 
drain (i.e., satisfy) pending allocation 
requests before deactivating sessions. It 
can specify drain separately for each of the 
source and target LUs. If drain is specified 
for an LU, that LU continues using sessions 
until there are no further 
transaction-program allocation requests for a 
session. If drain is not specified, the LU 
shuts down and deactivates the sessions as 
soon as the current transactions finish. 
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The operator can specify session-deactivation 
responsibility, i.e., it can request that 
either the source LU or the target LU take 
responsibility for any session deactivations 
required as a consequence of a particular 
verb issuance. Session limit decreases might 
leave the current session count in excess of 
the new limits. In this case, the LU with 
session-deactivation responsibility computes 
a termination count, which is the number of 
sessions 1t must deactivate to reach the new 
limits. Each LU has its own termination 
count, 1.@., one LU could be responsible for 
deactivating sessions to one Limit, but 
before it had done so, a subsequent verb 
could make the partner LU responsible for 
deactivating sessions from that limit to a 
newer limit. 


(LU,MODE) ENTRY 


The LU maintains an (LU,mode) entry for each 
defined combination of partner LU and mode 
name. This describes the dynamic relative 
state of the local and partner LU for that 
mode name. This includes the session limits, 
session counts, drain state, and termination 
count. 


DISTRIBUTED OPERATOR CONTROL 


Change number of sessions (CNOS) is a 
control-operator distributed function to reg- 
ulate the number of parallel sessions between 
a pair of LUs and to determine when sessions 
will be activated or deactivated. A CNOS 
verb issuance causes the source LU to negoti- 
ate with the target LU to establish a mutual- 
ly acceptable number of parallel sessions. 


LOCAL FUNCTIONS AND SERVICES 


Local control-operator verbs update 
definitional and operational parameters at 
the local LU without the participation of the 
operator at the remote LU. 


LU DEFINITION VERBS 


Lu definition verbs are local 
control-operator verbs that define or display 
the locally-kKnown characteristics of the 
local LU and of network resources it 
accesses. These resources and the principal 
characteristics that can be defined or dis- 
played are: 


* Local LU: the fully-qualified LU name 
and the optional capabilities the LU sup- 
ports such as parallel sessions and map 
names 


® Partner LUs: the various names of poten- 
tial partner LUs: local LU name; 


To do this, the control-operator transaction 
program at the source LU initiates a distrib- 
uted transaction, using a conversation, with 
the target LU. It uses the conversation to 
send a copy of the operator command to the 
partner LU and to receive a reply from the 
partner. 


At the target LU, the transaction program 
that constitutes the partner for this trans-~ 
action is the CNOS service transaction pro- 
gram (CNOS service TP), which tssues 
complementary control-operator verbs to 
receive the command and send a negotiated 
reply. The negotiation uses an 
implementation-defined algorithm that does 
not depend on interaction with a human opera- 
tor, 1.e@., it can run unattended, but it may 
use values supplied by that operator by ear- 
lier verb issuances, e.g., from LU definition 
verbs. The CNOS service TP may, however, use 
non-interactive implementation-defined means 
to inform the operator of any changes. 


Each program then changes its session limits 
and performs its local responsibility for 
deactivating sessions. 


The CNOS transaction requires use of a ses- 
sion. In order to allow operator commands to 
be exchanged regardless of the state of ses- 
sion traffic between the LUs, an SNA-defined 
mode name, SNASVCNG, is dedicated to sessions 
for the control-operator transactions. Each 
LU supports one session of each contention 
polarity for this mode name with each active 
partner LU. Thus, an LU can alnays obtain a 
contention-winner session to send a CNOS com- 
mand to its partner. 


fully-qualified LU name, and uninterpret- 
ed LU name; the optional capabilities of 
the partner LU such as parallel sessions; 
and the list of mode descriptions for 
that LU. 


e Modes: the mode name and optional func- 
tions that are supported by a partner LU 
on a mode basis, such as sync point; and 
session parameters that characterize this 
mode, such as maximum RU size, pacing 
counts, and cryptography. 


@ Transaction programs: the transaction 
program name, its avatlability, and the 
optional functions that it supports such 
aS map names and sync point. 


| The LU definition verbs consist of four 
| DEFINE verbs 


(DEFINE_LOCAL_LU, 


| DEFINE_REMOTE_LU, DEFINE_MODE; and 
| DEFINE_TP), four DISPLAY verbs (DIS- 
| PLAY_LOCAL_LU, DISPLAY_REMOTE_LU> DIS- 


| PLAY_MODE, and DISPLAY_TP), and one DELETE 
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| verb. 
| erence Manual for LU Type 6.2 for detailed 
| descriptions of these verbs. 


See SNA Transaction Programmer's Ref- 


LOCAL SESSION-CONTROL VERBS 


Local session-control verbs = are local 
control-operator verbs that set the session 
limits, contention polarity, and drain spec- 
ification for single-session mode names and 
for mode name SNASVCMG, or that activate and 
deactivate single or parallel sessions for 
any mode name. 


The local session-control verbs are the fol- 
lowing. 


®  INITIALIZE_SESSION_LIMIT sets the 
(LU,mode) session limit to allow one ses- 
sion, for a single-sessions mode name, or 
to allow one session of each contention 
polarity, for the parallel-session mode 
name SNASVCMG. This allows a session to 
be activated when requested by a trans- 


DISTRIBUTED FUNCTIONS AND SERVICES 


5.4-6 


CHANGE NUMBER OF SESSIONS VERBS 


Change number of sessions (CNOS ) 
control-operator verbs specify the maximum 
number of parallel sessions between two LUs, 
and, by implication, allow or require ses- 
sions to be activated or deactivated. The 
verbs also specify the minimum number of ses- 
sions allowed with each contention polarity. 
The verbs further specify whether the ses- 
sions are to be activated or deactivated 
immediately or according to the needs of 
transaction programs, and which LU is respon- 
sible for activating or deactivating sessions 
to attain or maintain the number of sessions 
within the agreed limits. 


CNOS verbs are distributed-function 
control-operator verbs; they take effect only 
with the mutual participation of both the 
control operator at the source LU and the 
CNOS service transaction program at the tar- 
get LU, which enforces constraints previously 
specified by the control operator at that LU. 
The CNOS verbs are: 

e INITIALIZE_SESSION_LIMIT 

® RESET _SESSION_LIMIT 

® CHANGE_SESSION_LIMIT 


® PROCESS_SESSION_LIMIT 


action program, or to be activated imme- 
diately (automatic activation) if so 
specified by a previously issued LU defi- 
nition verb. It also specifies the con- 
tention polarity to be selected when a 
session is activated by the local LU and 
the contention-polarity negotiation rule 
to be used when a session is activated by 
a remote LU. 


° RESET_SESSION_LIMIT sets the (LU,mode) 
session limits to 0 to cause deactivation 
of any currently active sessions and to 
disallow any further session activations. 
It also specifies the drain mode, indi- 
cating whether sessions are to be deacti-~- 
vated immediately or only when there are 
no remaining requests for their use. 


©  ACTIVATE_SESSION requests immediate acti- 
vation of a session. 


® DEACTIVATE_SESSION requests deactivation 
of a specific session. (This is the only 
control-operator verb that explicitly 
identifies a specific session.) 


(The INITIALIZE_SESSION_LIMIT and 
RESET_SESSION_LIMIT verbs are included in 
both the local verbs and CNOS verbs. They 
are distinguished by the characteristics of 
their specified mode name.) 

CNOS verbs control the number of parallel 
sessions by setting the (LU,mode) session 
Limit; this limits the corresponding 
(LU,mode) session count. 


A CNOS verb identifies the particular 
(LU,mode) entry that it affects, or it indi- 
cates that it affects all (LU,mode) entries 
for a given partner LU name. In the latter 
case, it affects all the (LU,mode) entries 
for the specified LU in the same way, e.g.» 
it applies the same drain specification and 
sessirc i-deactivation responsibility to all 
sessions. 


FUNCTIONAL RELATIONSHIPS FOR DISTRIBUTED VERB 
PROCESSING 


The complete processing function for a CNOS 
verb issuance is distributed among several 
components at both the source and the target 
LUs. Figure 5.4-2 on page 5.4-7 illustrates 
the relationships among the major LU compo- 
nents involved in processing a CNOS verb. 
Different components are active at the source 
and target LUs; only the components active 
for the LU's role are shown for that LU. 
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LEGEND: 


OPERATION PHASES 


eeeee> Call/return relationship (within a process) 

> Send/recetve relationship (between processes ) 
Access to shared data (within the LU) 
Transaction program interaction (between LUs) 


When the LU control operator invokes a CNOS 
function, the source and target LUs perform 2. 
the following functions, in four phases. 


1. Operator 
action Program 


Phase--Control-Operator Trans- 


At the source-LU, the control-operator 


transaction program 


receives 


a CNOS 


request from the LU control operator (Cin 


an implementation-defined way) 


and, on 


behalf of the LU control operator, issues 


a CNOS verb. 
invokes PS.COPR; 
phase. 


Chapter 5.4. 


The appropriate CNOS verb 
this begins the next 


Presentation 


LU Component Relationships for Distributed Session-Control Verbs 


Further details appear in 
"Control-Operator Transaction Program’ on 
page 5.4-22. 


Negotiation Phase--PS.COPR 


PS.COPR at the source LU initiates a con- 
versation with PS.COPR at the target LU, 
via the CNOS service transaction program 
at the target LU. Using the conversa- 
tion, the source LU sends a change number 
of sessions GDS variable (CNOS command) 
carrying an encoding of the parameters 
that were specified in the  CNOS 
control-operator verb. The target LU 
receives the CNOS command, negotiates 
acceptable session limits, drain specifi- 
cation, and session-deactivation respon- 
sibility, and sends the acceptable values 
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of the parameters back to the source LU 
in another change number of sessions GDS 
variable (CNOS reply). 


The two LUs then terminate their conver- 
sation and make the agreed-upon changes 
to their respective (LU,mode) entries. 
Each LU then determines whether it is 
responsible for changing the session 
count, and if so, notifies its resources 


manager that the limits have been 
changed. 
This phase is’ performed synchronously 


with the transaction program issuine the 
CNOS verb, 1.e., 1t complete. prior to 
return of contro! t. che control-operator 
transact*sis program. Further details 
erpear in "Session-Limit Services at the 
Source LU" on page 5.4-25 , "'CNOS Service 
Transaction Program" on page 5.4-22, and 
"Session-Limit Services at the Target LU" 
on page 5.4-28. 


Action Phase--Resources Manager 
The resources 


receives the 
notification 


manager (RM) at each LU 

sesston-limits-change 
(CHANGE_SESSIONS ) from 
PS.COPR. RM determines whether any ses- 
Sion activations or additional deacti- 
vations are required to bring the session 
count within the new session limits. If 
so, it performs the necessary session 
shutdown and issues requests for session 
deactivation to LU network services. For 
example: 


© If the current session count is less 


than the minimum = contentton-winner 
limit and is also less than the 
automatic-activation limit, RM 


requests activations to reach the 


lower of these Limits. 


° If the (LU,;mode) session limit is 
decreased and the current session 
count is between the previous limit 


and the new limit, RM shuts down and 
requests deactivation of the number 
of sessions necessary to reduce the 
session count from the present value 
to the new limit. 


° If the (LU,mode) session limit was 
decreased but the current session 
count is above the previous Limit, RM 
requests the additional deactivations 
necessary to reduce the session count 
from the previous limit to the new 
Limit (the RM with 
session-deactivation responsibility 
for the previous limit continues to 
request the deactivations that are 
necessary to reach that limit). 


° If the session count for either con- 
tention polarity encroaches on the 
minimum contention-winner limit for 
the opposite polarity, RM requests 
deactivations sufficient to allow the 


minimum of each polarity, even if 
this would reduce the (LU,mode) ses- 
sion count below the (LU,mode) limit. 


When RM determines that some sessions 
must be deactivated, it might be that a 
sufficient number of sessions are not 
immediately free. So, each RM maintains 
a count, the termination count, of the 
number of sessions for which it has 
sesston-deactivation responsibility. It 
increments this count whenever a Limits 
change requires the LU ‘tc cqeactivate 
additional sessions. It decrements this 
count when it requests a session deacti- 
vation. 


If the termination count is not 0, and 
the mutually-accepted drain specification 
so indicates, RM performs drain action, 
1.@.5 it continues to initiate conversa- 
tions until no requests for new conversa- 
tions for the specified LU name and mode 
name are pending from any transaction 
program. 


When drain action is completed, or if it 
was not requested, RM selects sessions of 
appropriate contention-polarity to be 
deactivated. It then shuts down all 
traffic on each selected session: after 
each partner LU ends its last bracket, it 
sends the BIS RU; when the = partner 
receives this,.it Knows that there are no 
more brackets in transit from its part- 
ner. RM then issues requests to LU net- 
work services to deactivate the selected 
sessions. 


This phase is performed asynchronously 
with the transaction program issuing the 
CNOS verb. (Details of these functions 
are discussed in Chapter 3.) 


Enforcement Phase--LU Network Services 


Whenever LU network services receives a 
request to activate a session from RM or 
from the remote LU (via the PU), it 
checks the current session counts and 
session limits to determine whether 
another session of that contention polar- 
ity is allowed. (The resources manager 
also assists in limits enforcement by 
checking the current counts and limits 
before Issuing session activation 
requests. ) If another session is 
allowed, LNS issues the appropriate BIND 
or response to BIND; otherwise, it 
rejects the request. 


Whenever LU network services receives a 
request to deactivate a session, it 
issues UNBIND or response to UNBIND. 


This phase is performed asynchronously 
with the transaction program issuing the 
CNOS verb and after the action phase. 
(For details of this phase, see Chapter 
4.) 
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The figure shows the verbs tssued and their most significant parameters. 


® Numbers in the left column refer to the explanation in the text. 
® Arrows represent information exchange resulting from verbs issued by the two transaction 


programs. 
5.4-10.) 


Figure 5.4-3. 


(For an explanation of the actual message units exchanged, see Figure 5.4-4 on page 


Sequence of Verbs and Information Exchange in CNOS Transaction Programs 


CNOS TRANSACTION 


The control-operator transaction program and 
the CNOS service transaction program, togeth- 
er with their corresponding PS.COPR compo- 
nents, process a distributed transaction to 
exchange the CNOS command and reply. The 
sequence of basic conversation verbs issued 
by PS.COPR at the source and target LUs is 
shown in Figure 5.4-3. The following com- 
ments correspond to the numbered Lines in 
that figure. 

1. The control-operator transaction program 
at the source LU issues one of the 
control-operator verbs INITIAL- 
IZE_ SESSION _LIMIT, CHANGE _SESSION_LINIT, 
or RESET _SESSION_LIMIT. This activates 
PS.COPR at the source LU (source-LU 
session-limit services, abbreviated 
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SSLS). SSLS builds the CNOS sonmmand and 
issues a sequence of conversation verbs. 


The source LU issues ALLOCATE to initiate 
a conversation with the target LU and to 
build an Attach FM header to invoke the 
CNOS service transaction program. 


When the target LU receives the Attach, 
it initiates the CNOS service transaction 
program. This program issues the PROC- 
ESS SESSION_LIMIT verb. This activates 
PS.COPR at the target LU (target-LU 
session-limit services, abbreviated 
TSLS}, which issues a sequence of conver- 
sation verbs complementary to those being 
issued at the source LU. 


TSLS issues the GET_TYPE verb to verify 
that this is a basic conversation. 


5.4-9 


Notes: 

Each arrow represents a chain, which comprises one or more request units. 

FMH-5( Attach TPN=X'06F1') is the encoding of the Attach from the ALLOCATE verbs. 

Request-header indication CD is the encoding of change-direction. 

GOS ID=X'1210' distinguishes the CNOS commard or reply record from other 6DS variables. 
Request-header indication CEB is the encoding of deallocate-normal. 

These flows are generated by the CNOS transaction as illustrated in Figure 5.4-3 on page 5.4-9. 


#e8¢¢ @ @ 


5. YSLS issues the GET_ATTRIBUTES verb to 
verify that the attributes of the conver- 
sation are those expected, and to get the 
partner LU name. The latter is used to 
resolve races between concurrent CNOS 
commands . 


6. SSLS issues SEND_DATA to send the CNOS 
comand to TSLS. 


Meanwhile, TSLS issues RECEIVE_AND_WAIT 
to receive the command. 


7. SSLS issues RECEIVE_AND WAIT to receive 
the reply from SSLS. This verb has the 
added effect of sending r) 
change-direction indication to TSLS, giv- 
ing TSLS permission to send. 


Meanwhile, TSLS issues RECEIVE _AND_WAIT 
to receive the change-direction  indi- 
cation. 


8. TSLS negotiates the proposed session lim- 
it parameters and builds the CNOS reply. 


9. TSLS issues SEND_DATA to send the reply 
to SSLS. 


When the reply arrives at the source LU, 
the RECEIVE_ANOD_WAIT verb previously 
issued by SSLS completes, and SSLS 
receives the reply. 


10. TSLS issues DEALLOCATE to end the conver- 
sation. This sends an indication to the 
source LU that the conversation is ended. 


Meanwhile, SSLS issues RECEIVE AND WAIT 
to receive the deallocation notification. 


li. SSLS issues DEALLOCATE to complete its 
processing of the conversation. 


12. Now both SSLS and TSLS have a copy of the 
negotiated reply record containing the 
agreed-upon limits, drain specification, 
and deactivation responsibility. They 
each update the session limits in their 
local data structures and inform the 
resources manager. : 


13. When SSLS and TSLS have finished process- 
ing the CNOS reply, they return to their 
respective callers, the transaction pro-~ 
grams that issued the CNOS verbs. These 
transaction programs then perform = any 
further implementation-defined actions, 
such as notifying the LU operators of the 
change. 


If, during the conversation, either LU 
detects a message unit or return code that 
does not conform to this protocol, it termi- 
nates the conversation by issuing DEALLOCATE 
TYPE( ABEND) (not shown in Figure 5.4-3), and 
the partner responds with  DEALLOCATE 
TYPE( LOCAL). 


(For further information on verb usage, see 
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Source LU Target LU 

Half—Session Hal f—Session 
o rs) 
.¥BB, RQE1, CD, FMH—-5( Attach TPN=X'O6FI'), GOSID=X'1210', command data ‘5 


rn 


° RQE1, CEB, GDSID=X'1210', reply data . 


Unless errors occur, the CNOS transaction always generates the same flow. 


Figure 5.4-4. 


5.4-10 


CNOS External Message-Unit Flows 


CNOS EXTERNAL MESSAGE-UNIT FLOWS 


The CNOS transaction presented in  "CNOS 
Transaction" on page 5.4-9 causes other LU 
components to generate the request chains 
shoom in Figure 5.4-4. This is the external 
representation of the information exchanged 
by the verbs. 


Exactly one bracket is initiated for each 
CNOS verb issued at the source LU. The 
bracket consists of exactly two chains, each 
containing exactly one Change Number Of Ses- 
sions 60S variable (CNOS command or CNOS 
reply). 


A single CNOS verb generates only one chain 
in each direction, even if MODE_NAME(ALL) is 
specified. In that case, the verb affects 
all mode names the same, e.g.» there is a 
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Figure 5.4-5. CNOS Process Interactions at a Single LU 


THE CNOS PROCESS RELATIONSHIPS TIALIZE_SESSION_LIMIT, CHANGE _SESSION_LIMIT, 
and RESET_SESSION_LIMIT. 


Processes The target transaction-program process con- 
tains the CNOS service transaction program. 
This program interacts with the internal LU. 
The LU components that support the CNOS func- components by issuing the PROC- 
tion are distributed among several processes, ESS_SESSION_LIMIT verb. 
as illustrated in Figure 5.4-5. 
(The transaction programs also interact with 


The source transaction-program process con- the = LU control operators in an 
tains the control-operator transaction pro- implementation-defined way. ) 

gram; this program interacts with the 

internal LU components by issuing Each transaction-program process also con- 


control-operator verbs, specifically, INI- tains within PS.COPR a session-limit services 
ee component (source or target), which processes 
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the control-operator verbs. 
CNOS control-operator verb, session-limit 
services interacts with other LU components 
and, indirectly, with its peer in the partner 
LU, by issuing basic conversation verbs, 
e.g.» ALLOCATE, SEND_DATA, RECEIVE_AND_WAIT, 
and DEALLOCATE. Session-limit services also 
accesses the (¢LU,mode) entries within the 
internal environment of the LU. : 


In processing a 


Multiple CNOS transaction-program processes, 
and corresponding half-session processes, can 
be active concurrently at any LU. For exan- 
ple, both the local control operator and a 
remote control operator might issue a CNOS 
verb at about the same time. Or two remote 
operators might both issue CNOS to the same 
LU. The local LU implementation might even 
allow two control-operator transaction pro- 
grams to be active at the same time. 


(Only one instance of the resources-manager 
process exists per LU.) 


an 


Shared Data 


An (LU,mode) entry is a shared data structure 
owned by the LU process (not shown). = An 
(LU, mode) entry exists for each combination 
of mode name and potential partner LU. Each 
(LU,mode) entry contains the session limits 
and other CNOS parameters affected by the 
CNOS verbs, such as the drain status. (It 
also contains other fields not used by CNOS. ) 


Each (LU,mode) entry also is associated with 
a session-limit-data lock field, that serves 
as a lock on that entry to prevent simultane- 
ous changes to the entry by different 
control-operator verb issuances. The state 
of the session-limit-data lock is maintained 


by the session-limit-data-lock manager 
(CSLDOLM), a PS.COPR component that each 


transaction-program process invokes to obtain 
or release exclusive use of an (LU,mode) 
entry. 
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Figure 5.4-6. Transaction Handling Component Relationships--Case 1: Single Verb Issuance 


Single Yerb Issuance: 
CNOS 
control-operator transaction program process 


§.4-12 


A single issuance of a 
verb uses unique instances of a 


and half-session process at the source LU and 
of a CNOS service-transaction program proc~ 
esses and half-session process at the target 
LU. These processes have shared access to 
the single instances of the resources manager 
process and the set of (LU,mode) entries at 
their respective LUs. These components, with 
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the conversation between them, process a sin- ances are contending for the same (LU,mode) 


gle CNOS transaction, as illustrated in Fig- entry, one of the issuances will fail. 
ure 5.4-6. 

To determine whether two transactions are 
Several different cases of process and trans- contending for the same (LU,mode) entry, and 
action relationships can occur when two CNOS 1f so, which one wins the contention, each 
verbs are issued concurrently at a local LU; transaction-program process invokes its 
at two partner LUs, or at both a local anda. session-limit-data-lock manager. Details of 
partner LU. If the two verb issuances are this contention detection and resolution are 
not contending for the same (LU,mode) entry, described in "CNOS Race Resolution" on page 
both verb issuances complete concurrently Cif 5.4-14. 


no errors occur). But if the two verb issu- 
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< > Send/receive relationship (between processes ) 
oe.ee. Access to shared data (within the LU) 

HERR Transaction—-handling boundaries 

eeeeee Process boundaries 

<seas> Transaction program interaction (between LUs) 


Figure 5.4-7. Transaction Handling Component Relationships--Case 2: Simultaneous Verb Issuances at 
Partner LUs 


Simultaneous Verb Issuances at Partner LUs: active, then if two CNOS verbs are issued 
When the LU is concurrently processing a CNOS concurrently at that LU, two  source-LU 
verb from both the local LU and from the transaction-program processes become active 
partner LU, for either the same or different at that LU, as illustrated in Figure 5.4-8 
(LU,mode) entries, both the source and the on page 5.4-14. If contention results, the 
target processes are active at each LU, as process handling the later verb issuance will 
illustrated in Figure 5.4-7. terminate without initiating a conversation 

with its partner. If no contention results, 
Simultaneous Verb Issuances at the Same LU: two source processes and transactions are 
If the local LU allows two control-operator active at the local LU. This case is not 
transaction programs to be concurrently illustrated, but is similar to Figure 5.4-7, 
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with the roles of source-LU and target-LU 
appropriately reversed. 


( 


LEGEND: 
< > 


o@e#eeee? 


HERR F 


@00000 
<RRNE> 


Notes: 
l. 


LU A 

SOURCE SOURCE 
HHRHHHHKKHHRHHH 
00008080800 # 0000680008000 # 
CNOS ® # @ CNOS ae 
Source @¢ (LU, # @ Source @ # 
Trans- @ | mode ) | # © Trans- © # 
action ...... entries ...... action ® # 
Program @ L—_______J] # © Program © # 
Process ® # © Process © # 
® > < # 
e | # © © # 
CE RETESET # CCOOOACOCOCS # 
Note 1) COOKCOVOOC® # # 
e RM e 6% + 
CRETE TITTY SE # B «4 
# OOCOOVOOCO®O t 
# @® Source © ¥# 
# ® Half- © # 
# © Session @ # 
# COCCHOACOOOO B 4 
a 4 


4 3¢ He He OH 


Send/receive relationship (between processes ) 


Access to shared data (within the LU) 
Transaction-handling boundaries 
Process boundaries 


Transaction program interaction (between LUs) 


RH HRT RF 


LU B 
TARGET TARGET 
HRHRRRKHHHKERHF 
# TERE EEE ES SE ¥# €060000600080 
# © CNOS ° % e CNOS e 
# © Target © # ® Target ©@¢ 
# *® Trans- © # ® Trans- @ 
# ¢® action ...... entries ® action ¢ 
# ¢ Program © # ® Program @ 
# ® Process ® # ® Process @ 
# © < ® (not e 
# © ° # | e active)e 
# ©9000 A00000 # 00000000008 
# # eeVescovee (Note 2) 
+ | # @ RM e 
# # 000086008 OO8 
# SCOCOVCCOOCe # 
# ® Target © # 
# ®@ Half- © # 
# © Session © # 
# PCOCHACOEOO # 
¥ z # 
a # 

# 

# 

# 
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The CNOS source transaction-program process attempts to lock an (LU,mode) entry in the 


LU_MODE_LIST after another source transaction-program had locked it but had not yet unlocked it. 
The later process is denied the lock and recognizes the contention; it goes away. 


rae 
act 


Figure 


ivated. 


5.4-8. 
the Same LU 


CNOS RACE RESOLUTION 


Command Race 


5 .4-14 


Two LU control operators might simultaneously 
issue a CNOS verb affecting the same LU name 
and mode name. If such a verb is’ issued 
while another such verb at either the source 
or the target LU is itn the negotiation 
phase, 1.e., a prior instance of PS.COPR is 
active on either LU for the same (LU,mode) 
entry or entries, a command race has 
occurred, and one (but not both) of the verbs 
fails. 


If a verb is issued when a previous verb is 
in the action phase, i.e., PS.COPR has 
already updated the (LU,mode) entry, but the 
resources manager and LU network services 
have not yet completed adjustments to the 


Transaction Handling Component Relationships--Case 3: 


A target transaction-program process corresponding to the failing source process is never 


Simultaneous Verb Issuances at 


session count, an action race has occurred 
and neither verb fails. For details, see SNA 
Transaction Programmer's Reference Manual for 
LU Type 6.2 and Chapter 3 of this volume. 


Locking the (LU,mode) Entry 


When a command race occurs, PS.COPR assures 
that exactly one of the commands completes 
successfully by observing a locking protocol 
for the (LU,mode) entry. The session-limit 
services routines invoke a shared component, 


SESSION_LIMIT_DATA_LOCK_MANAGER (abbreviated 
SLDLM hereafter), to prevent = simultaneous 
access to an (LU,mode) entry, to detect 
races, and to resolve double-failure race 


conditions. 


Source-LU session-limit services (SSLS) of 
PS.COPR tests and simultaneously sets the 
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CNOS lock in the (LU,mode) entry by issuing 
LOCK to its SLOLM before allocating a conver- 
sation to the target LU. If another instance 
of session-limit services has already locked 
the (LU,mode) entry, SSLS returns an error 
code. It does not send the CNOS command to 
the target LU or modify the session-limit 
parameters in the (LU,mode) entry. 


If SSLS succeeds, target-LU session-limit 
services (TSLS) at the partner LU issues LOCK 
to its SLOLM after receiving the CNOS command 
from the source LU. If TSLS finds the lock 
at its LU already set (for example, because a 
control-operator transaction program at its 
LU, acting as source LU, had simultaneously 
issued a CNOS verb), then TSLS sends the 
partner LU a CNOS reply with a reply-modi fier 
value indicating that a command race was 
detected. It does not modify the 
session-limit parameters in the (LU,mode) 
entry. 


In some cases, two commands issued simultane- _ 


ously frow each LU could both be rejected. 
For example, each LU might issue its command 
before the other arrived. Each target 
session-limit services would then reject the 
command from the partner because its source 
session-limit services had a comnand out- 
standing. This is called a double-failure 
race condition. To detect this case, SLDLM 
maintains another indicator, LOCK _DENIED. 
This is set by TSLS when it sends a 
command-race-detected reply modifier. 


When SSLS receives the reply frow TSLS, it 
checks the reply to determine whether the 
partner LU rejected the command because it 
detected a race. If so, it also tests the 
session-Llimit-data lock to determine if, 
meanwhile, its LU, acting as a target LU for 
another CNOS command, has rejected a command 
from the partner LU. SLDLM determines this 
from the LOCK_DENIED indicator. 
(LOCK_DENIED, together with the receipt of a 
command-race-detected reply modifier, indi- 
cates a double-failure race condition; 
either LOCK_DENIED or command-race-detected 
alone does not represent a double failure. ) 


Race Flows 


Example flows for the types of command races 
that can occur are shown in Figure 5.4-10 on 
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page 5.4-17, Figure 5.4-11 on page 5.4-18, 
and Figure 5.4-12 on page 5.4-19. The flows 
for the no-race case are shown in Fig- 
ure 5.4-9 on page 5.4-16 for comparison. 


In the figures: 


¢ The change number of sessions commands 
sent from each of the two LUs are on dif- 
ferent conversations. 


¢ The colums labeled "Transaction-x" show 
the actions performed by the CNOS 
transaction-program processes in process- 
ing a CNOS verb issued by the control 
operator at LUa. 


¢ The columns labeled ''Transaction-y" show 
the actions performed in processing a 
CNOS verb issued by the control operator 
at LUb. 


¢ The column labeled "(LU,mode) entry 
(LUb,m)" shows the changes made by the 
two transactions to the (LU,mode) entry 
for LUb, mode name wm at LUa. 


¢ The column labeled “(LU,mode) entry 
(LUa,m)" shows the changes in the corre- 
Sponding (LU,mode) entry for LUa, mode 
name m at LUb. 


¢ WMAX_SESS represents the session limit for 
mode name win the (LU,mode) entry. 


¢ SLD_LOCK represents the state (LOCKED, 


UNLOCKED, DENIED) of the 
session~-limit-data lock. 


The flows shonn are: 


¢ A CHANGE_SESSION_LIMIT verb (abbreviated 
CHANGE_SESSLIN) 


¢ The CNOS commands and replies exchanged 
by the CNOS transaction-program proc~ 


@SSe6S » 

¢ The internal requests (LOCK, TEST, 
UNLOCK) and their replies (OK, REJECT, 
DENIED ) 

¢ Update actions on the (LU, mode) 


session-limit field of the (LU,mode) 
entry 
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LUa LUb 


Transaction— x 
source process 


(1) 


(2) 


(3) 


(4) 


(5) 
(é) 


(7) 


(8) 


(LU, mode) 
entry 
~(LUb,m) 


Transaction-y 
target process 


MAX_SESS is n 
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.update (MAX_SESS(j)) 

SpE eee wae 
MAX_SESS is j ; 

.  "UNLOCK' 


6 EREDAR SOS S 
SDL_LOCK is UNLOCKED 


e e e e e e e e ° e e e 


Transaction-y 
source process 


CiwwS command (MODE(m) MAX_SESS(j)). 


< : 

‘LOCK ' : ‘ ; 

és Gueie Wie wos ee ae e e 

SDL_LOCK is LOCKED ‘ ‘ ‘ 

e ‘OK ' e e eo 

C666 hse SS eae e e 

: -CNOS reply (MODE(m) OK) . 
gee ei icles cna 


(LU,mode) | Transaction—x 
entry target process 
(LUa,m) . 


; MAX_SESS is n : 

‘ SDL_LOCK is UNLOCKED... 
CHANGE_SESSLIM(LU(a) MODE(m) MAX_SESS(}j)) 

; ‘LOCK’. ; | 

Cr ccccccccvecses® 

; SDL_LOCK is LOCKED 

: ‘OK’ ‘ 


Spee iene «ees 


-update (MAX_SESS(j)) 
Bios Soe gs ae eee 

: MAX_SESS is j 

° "UNLOCK' ° 

© oo eaeeg bok See 


. SDL_LOCK is UNLOCKED 


e e e e e ¢ od s e e e e e e e e ° e e e e e 


Note: Numbers in the left column refer to explanations in the text. 


Figure 5.4-9. 


54-16 


No Race: 


No Race: If only one LU issues a CNOS con- 
mand, no race occurs, and the transaction is 
successful. 


Figure 5.4-9 shows the no-race case. 
example: 


1. Before sending the CNOS command, the 
source LU (LUb) attempts to lock the 
affected (LU,mode) entry. 


2. Since no other CNOS transaction at LUb 
has the (LU,mode) entry locked, the 
attempt is successful. 


3. LUb now issues the CNOS command. 


4. When the target LU (LUa) receives the 
CNOS command, it attempts to lock the 
(LU,mode) entry. 


5. Since no other CNOS transaction at LUa 
has the (LU,mode) entry locked, the 
attempt is successful. 


6. LUa then negotiates and sends the CNOS 


reply. 


7. LUa then updates the (LU,mode entry). 


“Similarly, when LUb receives the reply, 
it also updates its (LU,mode) entry. 


Only One LU Issues a CNOS Verb 


In this. 


8. Both LUs unlock the (LU,mode) entries. 
The (LU,mode) entries are now available 
for updating by subsequent CNOS verbs. 


Single-Failure Races: In the single-failure 
cases (Figure 5.4-10 on page 5.4-17 and Fig- 
ure 5.4-11 on page 5.4-18), one transaction 
fails; it does not modify the session-limit 
parameters in the (LU,mode) entry. The other 
transaction succeeds and changes the 
session-limit parameters. 


Figure 5.4-10 on page 5.4-17 shows a 
single-failure race condition in which one 
transaction's command and reply both cross 
the reply of the transaction for a verb 
issued at the other LU. In this example, 


1. LUa's command succeeds because LUb was 
not busy when the command arrived. 


2. LUb's command fails because LUa's verb 


has not completed at LUa when LUb's com- 
mand arrives, even though LUa's verb 
processing has completed at LUb. 


3. When LUb receives the REJECT reply, it 
tests for LOCK_DENIED, which is not set, 
and so determines that no commariad from 
LUa (for mode name m) has been rejected 
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Figure 5.4-10. 


LUa 


Single-Failure Race Condition--Case 


and therefore does not attempt to retry 
the command. 


Figure 5.4-11 on page 5.4-18 shows another 
single-failure race condition, in which one 
transaction's command and reply cross the 
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LUb 


Transaction-x (LU,mode) Transaction-y Transaction-y (LU,mode ) Transaction-x 
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Note: Numbers in the left column refer to explanations in the text. 


mmand Crosses Reply 


command of the transaction for a verb issued 
at the other LU. In this example, 


1. LUb's command fails because LUa's command 


has not completed when LUb's command 
arrives. 
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NOTE: Numbers in left column refer to the explanations in the text. 


Figure 5.4-11. Single-Failure Race Condition--Case 2: Command and Reply Cross Command 


2. When LUb receives the REJECT reply, it 3. (Wa's command succeeds because LUb's 
tests LOCK_DENIED and determines that no unsuccessful command has already com- 
command from LUa (for mode name m) has _ pleted at LUb, and has released the lock, 
been rejected and therefore it does not before LUa's command arrives at LUb. 


attempt to retry the command. 
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(3) ‘ ‘ ; 
< 
. : "LOCK" ° ° ‘ "LOCK ' : 
e Nv gee Se ete oO aeee e aig aoe @e6e cs  aLee 
° SDL_LOCK is DENIED ° . SDL_LOCK is DENIED ° 
(4) ° ‘ "REJECT’ ° ‘ ; "REJECT' ; 
e © oie ae ee we See e DC CAME OLR 
‘ MAX_SESS is n (no change) MAX_SESS is n (no change) 
- ‘ -CNOS reply (MODE(m) “RACE_ REJECT) . 
. . ; 4 .CNOS reply (MODE(m) RACE _REJECT) 
(5) 2 ee eae 
< fae . . 
F ‘TEST’ : ; ; “TEST ' j ‘ 
eek ood oeeeee e ©. £66 6655 KERR EO e 
(6) : "DENIED ' ° "DENIED' : . 
er ee re ee eee @ Nigh beeéeeteewaera e 
(7) C'LUa' < 'LUb'S : : ('LUb' > 'LUa'; , : 
this LU will not retry) . this LU will retry). ‘ 
(8) . "UNLOCK ' . ° . . . 
de ee ee es e A e ° 
° SDL_LOCK is UNLOCKED ° . . 
(9) : ; -CNOS command (MODE(m) MAX_SESS(j)). F 
« e » nn e ° 
. ° *LOCK’ ° . . ° 
e Siti“ cet een * 2 e 
. SDL_LOCK 1s LOCKED ° . ° . 
@ e ‘OK ° 6 e e e 
Sd SO er eee era are 2 e e 
e ° -CNOS reply (MODE(m) ea ‘ ‘ 
: update (MAX_SESSS 52) Captaie (MAX_SESS(j)) : 
e 2 ee are, ee ee ie! © 6 Nae ESSA ° 
: MAX_SFSS js j ; ; MAX_SESS is j : 
° . ‘UNLOCK’ ° ; "UNLOCK ' . . 
@ Swe eee Ee © 66s WS oer esd 2 e 
* SDL_LOCK is UNLOCKED . . SDL_ LOCK is UNLOCKED . 


e e e e 


No*e: Numbers in left column refer to explanations in the text. 


Figure 5.4-12. Double-Failure Race Condition: Command Crosses Command, Renly Crosses Reply 


Double-Failure Race: In the double-failure discover the double failure and compare their 
case (Figure 5.4-12), both transactions ini- fully-qualifiéd LU names to resolve it. (For 
tially fail. The SSLS components at each LU the comparison, the fully-qualified LU names 


Chapter 5.4. Presentation Services--Control-Operator Verbs 5.4-19 


are left-justified and padded to the right 
with space [X'40'] characters to make the 
lengths equal.) The LU with LU name lower 
in EBCDIC collating sequence loses; the verb 
fails as in a single-failure race condition. 
The LU with LU name higher in EBCDIC collat- 
ing sequence retries the CNOS command, i.e., 
it allocates a new conversation and sends the 
same CNOS comand again. If no further 
errors occur, the verb eventually succeeds. 


Figure 5.4-12 on page 5.4-19 shows a 
double-failure case. In this example: 


1. Operators at both LUs = simultaneously 
issue CNOS verbs. 


2. The source processes successfully lock 
the (LU,mode) entries at their respective 
LUs, and issue CNOS commands. 


3. The commands cross in transit. 


4. When the commands arrive, the target 
processes attempt to lock the (LU,mode) 
entries but fail because they are already 
locked by the source processes of the 
other transaction, each of which has not 
yet received the reply to its ov com- 
mand. The failing attempt to lock also 
sets the LOCK_DENIED state of the lock. 
MAX_SESSIONS remains temporarily at n. 


5. Each target process sends a reply indi- 
cating a race reject. These replies also 
cross in transit. 


6. When the REJECT replies arrive, each 
source transaction program tests 
LOCK_DENIED and finds it set, indicating 
that a target transaction program at the 
same LU had attempted to set the lock but 


BASE AND OPTIONAL SUPPORT 


The basic and optional functions available at 
the control-operator protocol boundary are 
defined in SNA Transaction Programmer's Ref- 
erence Manual for LU Type 6.2. This section 
relates those functions to the capabilities 
of the components in the formal description. 


BASE~-FUNCTION-SET SUPPORT 


All implementations support an 
implementation-defined control-operator 
transaction program that is able to Issue any 
of the required (base function = set) 
control-operator verbs and all optional 
control-operator verbs and parameters that 
the LU supports. 


The base function set, supported by all 
implementations, includes the functions cor- 
responding to the LU definition verbs, i.e., 
the ability to specify the values of certain 
LU parameters that are chosen by the instal- 
lation. An implementation may support issu- 


had been refused. This is a double fail- 
ures the local LU's own command has 
failed, and wmeanshile the local LU has 
rejected a command from the partner LU. 


7. Each source process compares LU names to 
determine whether it should retry. 


8. The LU with low LU name (LUa) releases 
the lock and terminates its CNOS varb to 
avoid another race. 


9. The LU with the high LU name (LUb) 
re-issues the command. Processing con- 
tinues as in the no-race case (Fig- 
ure 5.4-9 on page 5.4-16). 


RECOVERY FROM CONVERSATION FAILURE 


If conversation failure, e.g.» session out~ 
age, were to occur during CNOS: processing, 
the CNOS command would not complete success- 
fully at the source LU. Nevertheless, it 
might complete at the target LU, for example, 
because the reply was lost after the target 
LU had already deallocated the conversation. 
In this case, the session limits could become 
different at the two LUs. 


To prevent this discrepancy, SSLS retries any 
command that fails because of conversation 
failure. Since the original session has been 
lest, SSLS attempts to obtain a new session 
on the same or another mode name. It first 
tries to obtain a session with the mode name 
that failed, then with mode name SNASVCMG Cif 
different), then with each mode name affected 
by the command, until either the command suc- 
ceeds or the LU determines that no session 
can be allocated with any affected mode name. 


ing these verbs from the control-operator 
transaction program. Alternatively, instead 
of exposing these verbs at the 
control-operator protocol boundary, the 
implementation may provide other support in 
the form of installation-time, IPL-time, or 
run-time processing of the system-definition 
values, as long as the values are initialized 
prior to first use. 


The base function set also includes local 
support of the functions of  INITIAL- 
IZE_SESSION_LIMIT and RESET_SESSION_ LIMIT 
that apply to single-session mode names, and 
includes receive support for remotely-issued 
ACTIVATE_SESSION and DEACTIVATE_SESSION 
verbs. 


All LUs providing an “open' protocol bounda- 
ry, 1.@., one to which application trans- 
action programs have access, also support 
parallel sessions, including the CNOS a@inimum 
Support (see "“CNOS Minimum Support Set" on 
page 5.4-21). 
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Parallel-session LUs optionally support 
optional function set parameters of the CNOS 
verbs (see "Parallel-Session Optional Func- 
tions". on page 5.4-21). 


LUs with a "closed" protocol boundary, i.e.; 
one to which application transaction programs 
do not have access, may optionally support 
parallel sessions and the corresponding CNOS 
minimum support. 


CNOS MINIMUM SUPPORT SET 


The CNOS minimum-support functions are: 


e Send (source) support for  IJINITIAL- 
IZE_SESSION_LIMIT 


This increases the session limit from 0. 


e Send support for RESET_SESSION_LIMIT 
RESPONSIBLE( SOURCE } DRAIN_SOURCE(NO) 
DRAIN_TARGETCYES) DRAIN_SOURCE( YES) 


This resets the session limit to 0. This 
does not allow the local LU to initiate 
new conversations after the verb com- 
pletes, but it allows the LU to accept 
new conversations initiated by a partner 
LU. 


® Receive (target) support for all CNOS 
verbs, except that: 


- The target LU may unconditionally 
change RESPONSIBLE( TARGET) to RESPON- 
SIBLE( SOURCE). 


- The target LU may unconditionally 
change DRAIN_TARGETC YES) to 
DRAIN_TARGET(NO). 


The minimum-support CNOS components are: 


e =O AN implementation-supplied 
control-operator transaction program that 
can issue the CNOS minimum-support verbs 


® The CNOS service transaction = program 
(TPN=X'06F1" ) 


° Presentation services for the control 
operator (PS.COPR), except for the 
optional functions listed in 
"Parallel-Session Optional Functions" 


® Support for ai sufficient number of 
reserved sessions using the SNA-defined 
mode name SNASVCMG 


The LU provides the capability for two 
such sessions for each LU with which the 
LU can have concurrently-active parallel 
sessions; these mode-name-SNASVCMG ses- 
sions are in addition to the sessions 


provided for user transactions. For each 
potential parallel-session partner LU, 
the operator specifies an (LU,mode) entry 
with mode name SNASVCMG and with limits 
allowing one contention-winner and one 
contention-loser session. 


(The SNA-defined mode name is provided so 
that PS.COPR will always be able to acti- 
vate a session to send the CNOS command, 
even when all other session limits are 
0, as in the initial state, or when all 
other active sessions are in in-brackets 
state or are bidder sessions on which a 
bid request is being refused. ) 


An LU that provides only the  CNOS 
minimum-support does not expose 
MIN_CONWINNERS_TARGET, RESPONSIBLE, or 
DRAIN_TARGET at the control-operator protocol 
boundary. In that case, the source LU sends 
MIN_CONWINNERS_TARGET(C implementation choice), 
RESPONSIBLE(SOURCE), and DRAIN_TARGETC YES) 
for those parameters that it does not expose. 


PARALLEL-SESSION OPTIONAL FUNCTIONS 


The optional parallel-session CNOS functions 
are: 


e¢ Receive support for DRAIN_TARGET( YES) 


This means that the LU supports local 
drain, 1.@., 1t is able to start new con- 
versations after the session limit is 
reset to 0 and to defer deactivating ses- 
Sions until there are no more local 
requests for new conversations. 


e Send support for any or all of the fol- 
lowing: 


= MIN_CONWINNERS_ TARGET 

- RESPONSIBLE( TARGET ) 

— DRAIN_TARGET(NO) 

This means that the LU exposes these 


parameters at the control-operator proto- 
col boundary. 


® Receive support for RESPONSIBLE( TARGET) 


This means the LU can be responsible for 
decreasing the session count to a nonzero 
value, i.e., it maintains an exact count 
of sessions to be terminated. 


© Send support for CHANGE_SESSION_LIMIT 
This means that the LU can increase or 


decrease the session limit to a nonzero 
value when it is currently nonzero. 
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COMPONENT INTERRELATIONSHIPS 


5 .4-22 


This section describes the functions and 
interrelationships of the components for 
control-operator functions. 


The principal components are: 


e Presentation services for the control 
operator (PS.COPR) 


®  Control-operator transaction program 
® CNOS service transaction program 


To perform its functions, PS.COPR may invoke 
the following other LU components: 


* Resources manager (RM), which performs 
session shutdown and invokes LU network 
services for session initi- 
ation/termination and acti- 
vation/deactivation 


e Presentation services for conversations, 
which uses an LU-LU half-session for the 
conversation with the partner LU. 


Figure 5.4-1 on page 5.4-2 illustrates the 
relationships among these components. 


TRANSACTION PROGRAMS 


Control- rator Transaction Program 


The control-operator transaction program is 
an  implementation-defined transaction pro- 
gram at the source LU that represents the LU 
control operator. It forms part of the 
local-Lu (source-LU) transaction-program 
process. It is invoked by presentation 
services (PS.INITIALIZE) as a result of an 
implementati on-def ined program-initiation 
request. | 


The control-operator transaction program may 
interact with a human operator, at the iwole- 


wentation- and/or installation-option, to 
obtain input parameters or to present 
results. It issues any of the supported 


control-operator verbs exposed at the 
control-operator protocol boundary. 


The transaction program passes to PS.COPR a 
transaction-program-verb structure speci fying 
the verb type and verb parameters. When 
PS.COPR processing is complete, the trans- 
action program 1s returned the same structure 
containing the returned parameter values, 
e.g.» a return code indicating success or a 
failure reason. 


CNOS Service Transaction Program 


The CNOS service transaction program is that 
SNA-def ined transaction program with 


transaction-program name (TPN) X'O6F1'. It 
represents the control operator at the target 
LU. It is invoked by presentation services 
(PS.INITIALIZE) when the target LU receives 
the Attach FM header that resulted from the 
ALLOCATE verb issued by PS.COPR at the source 
LU. 


The CNOS service transaction program per forws 
the following functions. 


e It is the target for the ALLOCATE verb 
issued by the source-LU control-operator 
transaction program. By being invoked, 
it completes the activation of the con- 
versation for the CNOS = transaction. 
(The characteristics of the conversation 
are discussed in section "CNOS Conversa- 
tion Allocation’ on page 5.4-27. The 
conversation parameters from the Attach 
FM header are verified by the resources 
manager and presentation services for 
conversations before this pregram is 
invoked. ) 


¢ It issues the PROCESS SESSION_LIMIT verb 
before any other processing. Thus, the 
CNOS service transaction program does not 
induce any undue delay, e.g., it does 
not wait on operator input. It also does 
not affect the values of the negotiable. 
parameters; these values are determined 
by an algorithm within PS.COPR. 


The CNOS service transaction program 
passes to PS .COPR a 
transaction-program-verb data structure 
specifying the verb type and identifying 
the return parameters for the CNOS verb. 
When PS.COPR processing is complete, the 
CNOS service transaction program is 
returned the same structure containing a 
return code indicating success or a fail- 
ure reason and other parameters tdentify- 
ing the (LU,mode) entry or = entries 
affected by the CNOS command. The PROC- 
ESS_SESSION_LIMIT verb does not provide 
the values of the session-limit parame- 
ters to the CNOS service transaction pro- 
gram; these values are available by 
issuing the DISPLAY verb. 


When control returns from the PROC- 
ESS_SESSION_LIMIT verb, the conversation 
with the source LU has already been deal- 
located and the session-liwit parameters 
have been updated at the target LU. 


* It performs an  itmplementation-defined 
action to notify its control operator of 
the activity. For example, it could 
trigger ano interrupt to the LU's 
control-operator transaction program (see 
section ‘“Control-Operator Transaction 
Program") to allow that program to exam- 
ine the new session-liwit parameters and 
display them for the cperator. 
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LEGEND: 
ere > Call/return relationship (within a process) 
< > Send/receive relationship (between processes ) 


Figure 5.4-13. Structure of Presentation Services for 


PS.COPR COMPONENTS 


Figure 5.4-13 shows the structure of PS.COPR. 
Its main components are: 

e The control-operator-verb router (repres- 
ented in the figure by the connecting 
arrows from the PS verb router to the 
various verb-handler routines) 


A verb handler for each verb (e.g., ACTI- 
VATE_SESSION_PROC, DEFINE PROC, DIS- 
PLAY_PROC, INITIALIZE_SESSION_LIMIT_PROC, 
PROCESS SESSION_LIMIT_PROC ) 

for 


Common verb-processing routines 


groups of verbs: 


Chapter 5.4. Presen 


distributed-function sesstor-lLimit verbs. 


the Control Operator 


= Local session-~Limit services for 
single-session mode names and (for 
mode name (LO- 


SNASVCMG 
CAL_SESSION_LIMIT_PROC ) 7 


Source-LU CNOS session-limit services 
(SOURCE_SESSION_LIMIT_PROC ) 


Target-LU CNOS session-limit services 
(combined with PROC- 
ESS_SESSION_LIMIT_PROC) 


The session-limit-data lock manager that 
controls contention between source-LU 
session-limit services (running on behalf 
of a locally-issued verb) and target-LU 
session-limit services (running on behalf 
of a remotely-issued verb}. 
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CNOS Verb Router 


The control-operator verb router component is 
the root procedure of PS.COPR. It is invoked 
by the PS verb router (see Chapter 5.0) when 
a transaction program issues a 
control-operator verb. It forms part of the 
transaction-program process. It is passed 
the transaction-program-verb structure 
(TRANSACTION_PGM_VERB) from the PS verb 
router, and passes this structure on to the 
corresponding verb handler. Upon regaining 
control from the verb handler, it returns to 
the PS verb router. 


LOCAL CONTROL-OPERATOR VERB PROCESSING 


Local-verb services comprises the verb han- 
dlers for two groups of local-function verbs: 
LU definition verbs and local session-control 
verbs. 


Lt! ScFINITION VERB PROCESSING 


The LU definition verbs include DEFINE and 


allow an implementation to define and display 
the parameters that are configuration depend- 
ent (i.e.,. the maximum number of sessions) 
and optional capabilities that are supported 
by the LU, the partner LUs, the MODES, and 
the transaction programs. i. 4 


The verb handler checks privilege to deter- 
mine that the requesting control-operator 
transaction program has DEFINE or DISPLAY 
privilege, as appropriate to the verb. It 
locates the relevant data structure and its 
containing structures using the Keys provided 
as verb parameters. It provides a return 
code indicating whether the operation was 
performed successfully. | 


The verb handler copies values from 
control-operator transaction program vari- 
ables into the LU data structures,» or vice 


versa; the trensaciion program never has 
direct access or addressability to the LU 
data structures. 


DISPLAY (see Figure 5.4-13). These verbs 
Verb Parameter Values Contention Polarity to be Used 
LU_MODE_ MINIMUM_ MINIMUM _ Polarity for Polarity Negotiation 
SESSION_ CONWINNERS  CONWINNERS_ Locally Activated for Remotely Activated 
LIMIT SOURCE TARGET Sessions Sessions 
0 % % parameter combination not allowed 
1 0 0 contention winner accept partner choice 
1 1 0 contention winner contention winner 
l 0 ] contention loser accept partner choice 
l 1 l parameter combination not allowed 
2or more * * parameter combination not allowed 
LEGEND: 
* any value 
Figure 5.4-14. Single-Session Contention Polarity Determined by Minimum-Contention-Winner-Limit 
Parameters 
LOCAL SESSION-CONTROL VERB PROCESSING parallel sessions, local verbs are used to 
initialize--to fixed session Limits--and to 
| reset the SNASVCMG mode name, because a ses- 
The session-activation verb handlers (e.g., Sion with this mode name must be activated 
ACTIVATE_SESSION_PROC) have an inter-process before the first CNOS command and reply can 
(send/receive ) relationship with the be sent.) This component has an 
resources manager for exchanging the inter-process (send/receive) relationship 
session-activation and -deactivation records. with the resources manager to notify RM of 
limits changes. 
The local session-limit services component 
(LOCAL_SESSION_LIMIT_PROC) provides the func- INITIALIZE SESSION LIMIT: When this verb is 
tions of the session-limit verbs for both issued for a single-session mode name or for 
Single-session mode names and “(for the mode name SNASVCMG, local session-Limit serv- 
parallel-session mode name SNASVCMG, i.e., ices checks session-limit constraints and 
| the SNA-defined mode name for used by CNOS. sets the (LU,mode) session limit at the local 
(Even though SNASVCMG~-mode-name sessions are LU. The partner LU does not participate in 
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setting the limits. Local session-limit 
services sends a change-sessions notification 
to the resources manager so that the 
resources manager may request activation of 
the allowed sessions according to _ its 
session-activation algorithm. 


For single-session mode names » local 
session-limit services also determines the 
contention polarity to be used when a session 
is activated by the local LU and determines 
the contention-polarity negotiation rule to 
be used when a session is activated by a 
partner LU. It determines these settings 
from the  minimum-contention-winner = Limit 
parameters of the verb, as specified in Fig- 
ure 5.4-14 on page 5.4-24. 


In the figure, the first three columns list 
possible combinations of verb parameter val- 
ues. The next column (locally activated ses- 
sions) specifies the corresponding 
contention-polarity choice that will be sent 
in a BIND RU issued by the local LU; the 
partner LU may negotiate contention-winner to 
contention-loser (1.e., make the partner LU 
the contention winner), but not the reverse. 
The next column (remotely activated sessions) 
specifies the contention-polarity that will 
be sent in the response issued by the local 
LU to a BIND from a partner LU. The local LU 
may change a received contention-loser into a 
contention-winner, but not the reverse. The 
last two columns also indicate those combina- 
tions of verb parameter values that are 
invalid with single-session mod” v.ames. 


For the naraLlel-session mode name SNASVCMG, 
th: verb parameters have their usual inter- 
pretation, but the only accepted values are: 


(LU,mode) session limit = 2») minimum 
contention-winner Limit (source) = 1, minimum 
contention-winner limit (target) = 1. 


RESET SESSION LIMIT: When this verb 1s 
issued for a single-session mode name or for 
mode name SNASVCMG, local session-Limit serv- 
ices checks session-Llimit constraints and 
sets the (LU,mode) session limit to 0 at the 
local LU. It also sets the drain speci fica- 
tion for the local and remote LUs. The part- 
ner LU does not participate in setting these 
limits. Local session limit services sends a 
change-sessions notification to the resources 
manager so that the resources manager will 
deactivate the specified sessions according 
to its drain and session-deactivation algo- 
rithms. 


For mode name SNASVCMG, local session-limit 
services also verifies that all other mode 
names for the specified partner LU are fully 
reset, 1.e., have (LU,mode) session Limit = 0 
and drain state NO. If so, it sets the ses- 
sion limits for mode name SNASVCMG to 0 and 
notifies RM to deactivate the 
SNASVCMG-mode-name sessions; otherwise, it 
does not change the limits but sets the 
appropriate return code. 


ACTIVATE SESSION: For this verb, 1f the TP 
has session control privilege, the verb han- 
dler sends a session-activation request to 


the resources manager, and receives a reply 
record indicating whether the session was 
successfully activated. 


DEACTIVATE SESSION: For this verb, if the TP 


has session control privilege, PS.COPR sends 
a session-deactivation request to the 
resources manager; the resources manager 
sends no reply, as session deactivation is 
assured. 


SESSION-LIMIT SERVICES AT THE SOURCE LU 


Source-LU session-limit services (SSLS) proc- 
esses CNOS verbs issued at the source LU. It 
forms a part of the source-LU 
transaction-program process that includes the 
control-operator transaction program. It is 
invoked via the presentation services (PS) 
verb router and PS.COPR when the 
control-operator transaction program issues a 
CNOS verb, and returns to the 
control-operator transaction program via the 
routers upon completing processing. 


SSLS interacts with other LU components as 
follows (see Figure 5.4-15 on page 5.4-26). 


A verb-handling routine corresponding to the 
specific verb CINITIALIZE_SESSION_LIMIT_PROC, 
CHANGE_SESSION_LIMIT_PROC, or 
RESFT_SESSICH LINIT_PROC), receives the verb 
parameters from the PS.COPR router. It then 
invokes the common session-limit services 
routine SOURCE_SESSION_LIMIT_PROC. It is 
returned the same structure with a return 
code, which it passes back to the PS.COPR 
router. 


SOURCE_SESSION_LIMIT_PROC is passed the CNOS 
verb parameters which it returns updated with 
a return code when its processing 1s com- 
plete. It performs the remainder of SSLS 
processing, as follows. 


e It verifies that the program issuing the 
verb 1s privileged to issue CNOS verbs. 


e It allocates a conversation with the tar- 
get. 


e Using that conversation, it sends a CNOS 
command record and receives a CNOS reply 
record 


¢ It invokes the’ session-limit-data~lock 
manager (see "'Session-Limit Data Lock 
Manager" on page 5.4-30) to prevent 
Simultaneous updating of the = same 
(LU;mode) entry, or entries, and to 
resolve races. 


® It updates the (LU,mode) entry with the 
accepted session-limit parameters. 


e If necessary, it notifies the resources 
manager to increase or decrease the cur- 
rent number of sessions. 
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1 See Chapter 5.1 for these interactions. 
2 PS router detail has been omitted. — 


Figure 5.4-15. Source-LU Component Interactions for CNOS 
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Privilege Checking 


SSLS examines the source-LU's transaction 
program list to determine whether the 
control-operator transaction program is 
authorized to issue CNOS verbs, i.e., whether 
it has change-number-of-sessions privilege. 
If not, SSLS causes the verb to fail. 


(Since the target transaction program has a 
privileged transaction-program name, i.e.» 
TPN less than X'40', presentation services 
for conversations also verifies, by checking 
the transaction-program list at the source 
LU, that the transaction program issuing the 
ALLOCATE is allowed to tnvoke privileged pro- 
grams. ) 


CNOS Conversation Allocation 


SSLS allocates a conversation with the target 
LU to exchange the CNOS command and reply. 
The conversation requires only conversation 
verbs in the base set, but an implementation 
may use verbs and parameters from the 
locally-supported "performance" option sets 
that do not require remote support (see SNA 


Transaction Programmer's Reference Manual for 
LU Type 6.2). 


The following subsections discuss the allo-~- 
cation parameters for the conversation. 


LU name: SSLS uses the target LU name sup- 
plied by the CNOS verb. 


Mode name: SSLS . uses an 
implementation-defined algorithaw to select a 
mode name for the CNOS conversation; for 
example, the algorithm can select a mode name 
for which a session is currently active and 
available. If no session is available on any 
other implementation-selected mode name, SLSS 
uses the SNA-defined mode name SNASVCMG. It 
also uses SNASVCMG for the first CNOS verb 
issued by the LU, j.e.») when no sessions are 
active for other mode names and the session 
limits for all mode names (except SNASVCMG) 
are all 6. 


(The operator previously initializes the ses- 
sion limits for wmode name SNASVCMG to 
MAX_SESSIONS(2),; MIN_CONWINNERS SOURCE(1), 
and MIN_CONNINNERS_TARGET(1), so that the 
source LU may always succeed in activating 
one contention winner session to send the 
CNOS command and reply.) 


Type: Basic Conversation 


Transaction Program Name: SSLS establishes 
the conversation with the CNOS service 
transaction program, whose SNA-defined trans- 
action program name (TPN) is X'O6FI', at the 
target LU. 


Security: The CNOS conversation uses SECURI- 
TYCNONE ). . 


Synchronization Level: The CNOS conversation 
uses SYNC_LEVEL(NONE ). 
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Recovery Level: The CNOS conversation uses 
RECOVERY_LEVEL(NONE ). 


Program Initialization Parameters: The CNOS 
conversation does not use program initializa- 
tion parameter data, j.e., it uses PIP(NO). 


GDS Variable 


SSLS builds a CNOS command containing the 
verb and parameter information passed from 
the CNOS service transaction program = and 
sends it to the target transaction program. 
The Change Number of Sessions GDS variable 
and the CNOS command and reply are described 
in “Appendix H. FM Header and LU Services 
Commands". It receives from the target 
transaction program a similar CNOS reply con- 
taining a reply code that indicates either 
that the command was accepted or the reason 
for its rejection. 


CNOS Record Flows 


SSLS generates a conversation between the 
source-LU and the target-LU transaction pro- 
grams. The sequence of conversation verbs 
issued by SSLS, and the complementary verbs 
issued by the partner program SES- 
SION_LIMIT_SERVICES_TARGET, are showm in Fig- 
ure 5.4-3 on page 5.4-9. 


Errors 


SSLS analyzes the CNOS verb parameters for 
transaction program errors, checks the return 
codes from conversation verbs for conversa- 
tion errors such as session failure or proto- 
col violation, and analyzes the CNOS reply 
for target-detected errors or changes to 
negotiable parameters, and determines = the 
proper return code for the CNOS verb. 


If conversation failure (session outage) 
occurs, the source LU retries the CNOS con- 
mand as described in "Recovery from Conversa- 
tion Failure" on page 5.4-20. 


Update (LU,mode) Entry 


If the command and reply exchange is com- 
pleted without error, SSLS updates the 
session-limit parameters for the specified 
(LU,;mode) entry using the new values of 
LU_MODE_SESSION_LIMIT, MIN_CONWINNERS_ SOURCE, 
MIN_CONWINNERS_TARGET, | RESPONSIBLE, = and 
DRAIN_TARGET from the reply record. If the 
command specifies MODE_NAME(ALL), the limits 
for all mode names defined for the specified 
LU name, except the SNA-defined mode name 
SNASVCMG, are updated. SSLS then invokes the 
session-limit-data lock manager to unlock the 
entries it locked (see "Session-Limit Data 
Lock Manager" on page 5.4-30). 
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The new limits are enforced by the resources 
manager (see "Chapter 3. LU Resources Manag- 
er") and by LU network services (see "Chapter 
4. LU Network Services"). 


Request Changes in Session Count 


If the CNOS command action is Set, or if it 


designates the source LU as responsible for 
session deactivation, SSLS issues a 
CHANGE_SESSIONS request, identifying the 
affected LU name and wmode names, to the 
resources manager (RM). If MODE_NAME(ALL) is 
specified, SLSS sends a separate 
CHANGE_SESSIONS request for each mode name 
except mode name SNASVCMG. 


The CHANGE SESSIONS request notifies RM that 
the session limit parameters have changed and 
that, as a consequence, RM may make changes 
to the number of sessions. RM determines the 
actual changes to be made to the session 
count and issues appropriate requests to LU 
network services to activate or deactivate 
sessions. 


Return to the Transaction Program 


When the above functions are completed, S5LS 
returns to the control-cperator transaction 
program, passing back the appropriate return 
code in the transaction-program-verb struc- 
ture. 


SESSION-LIMIT SERVICES AT THE TARGET LU 


Target-LU session-limit services (TSLS) proc- 
esses the CNOS verbs issued at the target LU. 
It functions in a manner complementary to 
SSLS (see "Session-Limit Services at the 
Source LU" on page 5.4-25). It forms a part 
of the target-LU transaction-program process 
that includes the CNOS service transaction 
program. It is invoked via the presentation 
services (PS) verb router and the PS.COPR 
router when the CNOS service transaction pro- 
gram issues the PROCESS SESSION_LIMIT verb; 
it returns to the CNOS service transaction 
program upon completion of processing. 


TSLS interacts with other LU components as 
follows (see Figure 5.4-16 on page 5.4-29). 


®* It receives the transaction-program-verb 
structure representing the PROC ~ 
ESS_SESSION_LIMIT verb 


When its processing is complete, It 
returns to the CNOS service transaction 
program, passing back the 
transaction-program-verb structure 
updated with a return code and the iden- 
tity of the affected (LU,mode) entries. 
(The latter may be used by the implemen- 
tation to inform the control operator of 
the changes. ) 


® It determines whether the issuing trans- 
action program is the CNOS service trans- 
action program (TPN=X'06F1') and has the 
change~number-of-sessions privilege. If 
not, TSLS abnormally terminates the 
transaction program, which causes the LU 
issue DEALLOCATE TYPE( ABEND) on the con- 
versation. 


¢ It communicates with SSLS at the source 
LU, using the conversation with which the 
CNOS service transaction program = was 
attached, by issuing conversation verbs 
to presentation services for conversa- 
tions. 


® It receives a CNOS command from the 
source LU, changes the source LU's 
requested session-limit parameters to 
values acceptable to the target LU, if 
necessary, and sends a CNOS reply, with 
the same format, back to the source LU. 


¢ It invokes the session~-limit-data-lock 
manager (see "Session-Limit Data Lock 
Manager" on page 5.4-30) to prevent 
simultaneous updating of any (LU,mode) 
entry. 

affected 


e It updates the (LU, mode) 


entries. 


o If necessary, it notifies the resources 
manager to increase or decrease the cur- 
rent number of sessions. 


CNOS Reply 


TSLS receives from the source-LU transaction 
program a CNOS command record containing the 
verb and parameter information passed from 
the control-operator transaction program. It 
builds a similar CNOS reply record containing 
the acceptable values of the negotiable 
session-limit parameters--see “Session-Limit 
Parameter Negotiation'--and a reply code, 
which either indicates that the command was 
accepted or gives the reason for its 
rejection, and sends it to the source LU. 


Session-Limit Parameter Negotiation 


TSLS executes an implementation-determined 
algorithm to accept or modify the negotiable 
session-limit parameters received from the 
source LU, subject to the negotiation rules 
given below. It sets the Reply Modifier 
field in the CNOS reply to indicate whether 
the all parameters were accepted as received 
or whether any were negotiated to new values, 
and sends it with the received or modified 
values to the source LU in the CNOS reply. 
(The source LU accepts any modified values 
that satisfy the negotiation rules. ) 


The negotiation rules are as follows. (In 
the formulas, variables prefixed with C_ 
refer to values of verb parameters speci fied 
by the source LU in the CNOS command record; 
variables prefixed with R_ refer to values of 
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these parameters as modified by the target LU 
and returned in the CNOS reply record. 


If the command action is Set (INITIALIZE_ or 


CHANGE _SESSION_LIMIT verb issued): 


Chapter 5.4. 
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6 If the current (LU,mode) session count is 


0; then, based on an 
implementation-defined decision, the LU 
may refuse to accept the command by 


returning an abnormal reply with 
reply-modifier value abnormal--(LU,mode) 
session limit is 0. Both LUs then ignore 


5.4-29 


5.4-30 


the session-Limit 
reply; 


parameters of the 
they do not change the current 


session-limit parameters in the 
(LU,mode) entry. 
® The target LU may decrease 


LU_MODE_SESSION_LIMIT to a lower ramber 
of sessions, but not to 0, i.e., the new 
value satisfies: 


0 < R_LU_MODE_SESSION_LIMIT < 
C_LU_MODE_SESSION_LIMIT. 


® If the proposed source contention winners 
(C_MIN_CONWINNERS_ SOURCE ) exceeds 
R_LU_MODE_SESSION_LIMIT/2, the target LU 
may change MIN_CONWINNERS_ SOURCE to any 
lower value not less than 
R_LU_MODE_SESSION_LIMIT/2 rounded down- 
ward, 1.@., the new value satisfies: 


C_MIN_CONWINNERS_ SOURCE 2 
R_MIN_CONWINNERS SOURCE 2 


MIN(C_MIN_CONWINNERS_ SOURCE , 
R_LU_MODE_SESSION_LIMIT/2). 


® The target LU may change its own minimum 
contention-winner limit 
(R_MIN_CONWINNERS TARGET) to any value 
not exceeding the difference between the 
total session limit and 
MIN_CONWINNERS SOURCE, j.e., the new val-~- 
ue satisfies: 


0 S$ R_MIN_CONWINNERS_ TARGET < 


(R_LU_MODE_SESSION_LIMIT - 
R_MIN_CONWINNERS_ SOURCE ). 


® The target LU may change RESPONSIBLE to 
SOURCE. 


If the command action is Close for only one 
mode name (RESET_SESSION_LIMIT 
(MODE_NAME(ONE,...) issued): 


® If the (LU,mode) session count is 0 and 
the current drain state is NO, then, 
based on an implementation-defined deci- 
sion, the target LU may refuse to accept 
the command by returning an abnormal 
reply with reply modifier abnor- 
mal--(LU,mode) session limit is 0. Both 
LUs then ignore the session-limit parame- 
ters of the reply; they do not change the 
current session-liwit parameters in the 
(LU, mode) entry. 


® The target LU may change RESPONSIBLE to 
SOURCE. 


e The target LU may change its own drain 
action (DRAIN_TARGET) from YES to NO. 


e The target LU 
DRAIN_SOURCE. 


dees not change 


If the command action is Close for all mode 
names (RESET_SESSION LIMIT (MODE_NAME(ALL) 
issued): 


© If the (LU,mode) session count is 0 and 
the current drain state is NO for all 
mode names with the partner LU, then, 
based on an implementation-defined deci- 
Sion, the target LU may refuse to accept 
the command by returning an abnormal 
reply with reply  wodifier abnor-=- 
mal--(LU,mode) session limit is 0. Both 
LUs then ignore the session-limit parame- 
ters of the reply; they do not change the 
current session-limit parameters in the 
(LU,mode) entry. 


¢ The target LU may change RESPONSIBLE to 
SOURCE. If so, it changes all mode names 
not already at SESSION_LIMIT = 0 to the 
same (SOURCE) responsibility. 


® The target LU does not send a changed 
value for DRAIN_TARGET in the reply, but 


echoes the value received. Nevertheless, 
if the command speci fies 
DRAIN_TARGET(YES), and the current ses- 


sion limit is not zero, the target LU may 
set its local drain state for any wmode 
names to either YES or NO, regardless of 
the previous drain state. If the current 
session limit is already zero and the 
drain state is no, the drain state for 
that mode is left unchanged. 


¢ The target LU does not change 
DRAIN_SOURCE. 
rror 


If TSLS detects a condition that precludes 
performing the nominal action (e.g., a race 
condition or wumrecognized mode name), but 
that does not violate architectural rules, it 
sends an abnormal reply with the appropriate 
reply modifier (see “Appendix H. FM Header 
and LU Services Commands" for reply-modi fier 
codes ). 


If it detects an 
source LU, e.g.» 


invalid comeand from the 
undefined or disallowed 


parameter values, it treats this as a proto- 


col violation. TSLS does not change the CNOS 
parameters or send a reply, but instead 
issues DEALLOCATE TYPE(ABEND). TSLS 3lso 
reports any errors detected to the CNOS serv- 
ice transaction program via the 
transaction-program-verb structure. 


Other Interactions 


Other TSLS interactions are similar to the 
corresponding interactions of SSLS. 


SESSION-LIMIT DATA LOCK MANAGER 


Locking the (LU,mode) Entry 


The session-limit services routines invoke a 
shared component > SES- 
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SION_LIMIT_DATA_LOCK_MANAGER (SLDLM), to pre- 
vent simultaneous access to an (LU,mode) 
entry, to detect races, and to resolve 
double-failure race conditions, as described 
in “CNOS Race Resolution" on page 5.4-14. 


SLDOLM is a shared routine, invoked from both 
SSLS and TSLS> that maintains the 
session-limit data lock. A_ session-limit 
data lock exists for each (LU,mode) entry. 
It is in one of the following states: 


UNLOCKED: No CNOS component is currently 
using the (LU,mede) entry. The 
lock is reset to this state whenev- 
er the process that locked it com- 
pletes processing. 


LOCKED_BY_SOURCE: SSLS has locked the 
(LU,mode) entry to process a CNOS 
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command issued at the local LU. 
The lock had previously been in 
UNLOCKED state. 


LOCKED_BY_TARGET: TSLS has locked the 
(LU,mode) entry to process a CNOS 
command issued at a remote LU. The 
lock had previously been in 
UNLOCKED state. 


LOCK_DENIED: While the lock NaS in 
LOCKED_BY_SOURCE state, TSLS 
attempted to lock it on behalf of a 
remotely-issued verb. TSLS was 
refused. 


This state allows SSLS to determine 


whether a double-failure race 
occurred. 


5.4-31 


VERB-ROUTING PROCEDURE 


5.4-32 


PS_COPR 
FUNCTION: This procedure receives: all control-operator verbs issued by the transaction 
program and routes the input to the appropriate procedure for processing. 
is invoked by and returns to the presertation-services verb router and forms 
part of the transaction-program process. 
INPUT: CNOS verb parameters, received from caller, updated by called procedures 
OUTPUT: Updated return code and verb-specific returned parameters 


Referenced procedures, FSMs, and data structures: 


INITIALIZE_SESSION_LIMIT_PROC page 5.4-33 
CHANGE_SESSION_LIMIT_PROC page 5.4~-35 
RESET_SESSION_LIMIT_PROC page 5.4-34 
PROCESS _SESSION_LIMIT_PROC page 5.4-58 
ACTIVATE_SESSION_PROC page 5.4-36 
DEACTIVATE_SESSION_PROC page 5.4-37 
DEFINE_PROC page 5.4-38 
DISPLAY_PROC page 5.4-39 
DELETE_PROC page 5.4~40 


Select based on type of verb parameters: 
When INITIALIZE _SESSION_LIMIT 


Call INITIALIZE_SESSION_LIMIT_PROC with the verb parameters (page 5.4-33). 


When CHANGE SESSION LIMIT 


Call CHANGE_SESSION_LIMIT_PROC with the verb parameters (page 5.4-35). 


When RESET_SESSION_LIMIT 


Call RESET_SESSION_LIMIT_PROC with the verb parameters (page 5.4-34). 


When PROCESS_SESSION_LIMIT 


Call PROCESS SESSION_LIMIT_PROC with the verb parameters (page 5.4-58). 


When DEACTIVATE_SESSION 


Call DEACTIVATE_SESSION_PROC with the verb parameters 


(page 5.4~-37). 


When ACTIVATE_SESSION 
Call ACTIVATE_SESSION_PROC with the verb parameters (page 5.4-36). 


When DEFINE_LOCAL_LU, DEFINE_REMOTE_LU, DEFINE_MODE, or DEFINE_TP 
Call DEFINE_PROC with the verb parameters (page 5.4-38). 


When DISPLAY_LOCAL_LU, DISPLAY_REMOTE_LU, DISPLAY MODE, or DISPLAY_TP 


Call DISPLAY_PROC with the verb parameters (page 5.4~-39). 
When DELETE 
Call DELETE_PROC with the verb parameters (page 5.4-40). 
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SESSTON-CONTROL VERB HANDLERS 


INITIALIZE SESSION_LIMIT_PROC 


This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues an INITIALIZE_SESSION_LIMIT verb. It determines 
the connection type (single or parallel). If the connection is single-session 
or the mode name is SNASVCMG, it passes the CNOS verb parameters to 
LOCAL_SESSION_LIMIT_PROC; if the connection is parallel-session, it passes the 
CNOS verb parameters to SOURCE_SESSION_LIMIT_PROC. It passes the return code 
to the original caller. If an ABEND condition occurs, it calls PS to abnor- 
wally terminate the transaction-program process. 


INITIALIZE _SESSION_LIMIT verb parameters from callers CNOS RETURN_CODE from 
LOCAL_ or SOURCE_SESSION_LIMIT_PROC 


RETURN _CODE of INITIALIZE_SESSION_LIMIT to caller 


Referenced procedures, FSMs, and data structures: 


SOURCE_SESSION_LIMIT_PROC page 5.4-46 
LOCAL_SESSION_LIMIT_PROC page 5.4-41 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
LUCB page A-1 


If this transaction program is not authorized to issue the CNOS verb then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) 


to abnormally terminate this instance of the transaction program 
(control is not returned). 


Else 


Using the LUCB, determine the type of sessions possible with 
the partner LU, either single or parallel. 


For parallel session connections, an LU may elect not to expose the 
MIN_CONWINNERS TARGET parameter at the control-operator protocol 
boundary. In this case, the implementation may choose any value that 
satisfies the description of this parameter in SNA Transaction Pro- 
gramer's Reference Manual for LU Type 6.2. 


If the specified LU is not defined as a partner LU for this LU then 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 


Else 
If the type of cormection is parallel sessions 
and the mode name is not SNASVCMG then 
Call SOURCE_SESSION_LIMIT_PROC (page 5.4-46), 


with the verb parameters, to begin the negotiation phase of the CNOS 
process. 


Else (local control-operator verb) | 
Call LOCAL_SESSION_LIMIT_PROC (page 5.4-41); 


with the verb parameters, to perform the CNOS action solely at the 
local LU. 
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RESET_SESSION_LIMIT_PROC 


54-34 


RESET_SESSION_LIMIT_PROC 


This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues a RESET_SESSION_LIMIT verb. It determines the con- 
nection type (single or parallel). If the connection is single-session or the 
mode name is SNASVCMG, it passes the CNOS verb. parameters to 
LOCAL_SESSION_LIMIT_PROC; if the connection is parallel-session, it passes the 
CNOS verb parameters to SOURCE _SESSION_LIMIT_PROC. It passes the return code 


to the original caller. If an ABEND condition occurs, it calls PS to abnor- 
mally terminate the transaction-program process. 


RESET_SESSION_LIMIT verb parameters from callers; CNOS RETURN_CODE from LOCAL_ 
or SOURCE _SESSION_LIMIT_ PROC | 


RETURN_CODE of RESET_ SESSION. LIMIT verb. to caller 


Referenced procedures, FSMs, and data structures: 
SOURCE_SESSION_LIMIT_PROC | page 5.4-46 


LOCAL_SESSION_LIMIT_PROC | = * page 5.4-41 
CHANGE_ACTION oe - page 5.4~-44 
DEALLOCATION_CLEANUP_ PROC ee © — page 5.0-13 
LUCB page A~-] 


If this transaction program is not authorized to issue the CNOS verb then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) 
to abnormally terminate this instance of the transaction program 
(control is not returned). 


Else 
Using the LUCB, determine the type of sessions possible with 
the partner LU, either single or parallel. 


For parallel-session connections, an LU may elect not to expose the 
DRAIN_TARGET, and RESPONSIBLE parameters at the control-operator pro- 
tocol boundary. In this case, the implementation provides default 
values for these parameters consistent with the description on page 
5.4-21. 


For single-session connections, the RESPONSIBLE parameter on the verb 
is not used. It is forced to SOURCE. 


For the SNA-defined mode name, SNASVCMG, the DRAIN_SOURCE; 
DRAIN_TARGET, and RESPONSIBLE parameters on the verb are not used. 
They are forced to NO, NO, SOURCE, respectively. 


If the specified LU is not defined as a partner LU for this LU then 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 


Else 
If the type of connection is parallel sessions | 
and the mode name is not SNASVCMG then = 
Call SOURCE_SESSION_LIMIT_PROC (page 5.4-46), 
with the verb parameters, to begin the negotiation phase of the CNOS process. 
If FORCE = YES is specified on the RESET_SESSION_LIMIT verb then 
If the CNOS return code indicates ALLOCATION_ERROR-ALLOCATION _FAILURE_NO_RETRY, 
LU_MODE_SESSION_LIMIT_CLOSED, RESOURCE _FAILURE_NO_RETRY or 
UNRECOGNIZED_MODE_NAME then 
Change RESPONSIBLE to SOURCE. 
Call CHANGE_ACTION (page 5.4-44) with the CNOS request to 
update the limits in the MODE structure(s) for the source LU and notify RM. 
Set the CNOS return code to OK-FORCED. 


Else (local control-operator verb) 


Call LOCAL_SESSION_LIMIT_PROC (page 5.4-41), 
nith the verb parameters, to perform the CNOS action solely at the local LU. 
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CHANGE_SESSION_LIMIT_PROC 


CHANGE_SESSION_LIMIT_PROC 


FUNCTION: 


INPUT : 


OUTPUT: 


This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues a CHANGE_SESSION_LIMIT verb. It passes the CNOS 
verb parameters to SOURCE_SESSION_LIMIT_PROC and passes the return code to 
the original caller. If an ABEND condition occurs, it calls PS to abnormally 


terminate the transaction-program process. 


CHANGE_SESSION_LIMIT parameters from caller; CNOS  RETURN_CODE from 
SOURCE_SESSION_LIMIT_PROC 


RETURN_CODE of CHANGE_SESSION_LIMIT to caller 


Referenced procedures, FSMs, and data structures: 


SOURCE_SESSION_LIMIT_PROC page 5.4-46 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
LUCB page A-l 


If the control-operator transaction program, at the source LU, 
1s not authorized to issue the CNOS verb then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) 
to abnormally terminate this instance of the transaction program 
(control is not returned). 


Else 


Using the LUCB, determine the type of sessions possible with 
the partner LU, either single or parallel. 


An LU) might = elect not to expose the RESPONSIBLE and 
MIN_CONWINNERS TARGET parameters at the control-operator protocol 
boundary. In this case, the implementation provides default values 


for these parameters consistent with the description on page 5.4-21 
and the parameter specification in SNA Transaction Programmer's Refer- 
ence Manual for LU Type 6.2. 


If the specified LU is not defined as a partner for this LU then 


Set 


Else 


the CNOS RETURN_CODE to PARAMETER_ERROR. 


If the type of connection is parallel sessions and the mode name is not SNASCVMG the 
Call SOURCE_SESSION_LIMIT_PROC (page 5.4-46), 


Else 


with the verb parameters, to begin the negotiation phase of the CNOS process. 


Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) 


to abnormally terminate this instance of the transaction program 
(control is not returned). 
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ACTIVATE_SESSION_PROC 


ACTIVATE_SESSION_PROC 


FUNCTION: This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues an ACTIVATE_SESSION — verb. It sends an 
RM_ACTIVATE_SESSION request to RM to activate a session, and receives’ the 
reply indicating whether the session was activated. 


INPUT: The CNOS verb (ACTIVATE_SESSION), the reply from RM (RM_ACTIVATE_SESSION) 


OUTPUT: The request to RM (RM_ACTIVATE_SESSION), RETURN_CODE of ACTIVATE_SESSION verb 


NOTE: This procedure has addressability to RM via PS_PROCESS_DATA.LU_ID. 


Referenced procedures, FSMs, and data structures: 


RM page 3-18 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
PS_PROCESS_DATA page 5.0-19 
RM_ACTIVATE_SESSION page A-27 
RM_SESSION_ACTIVATED page A-33 


Verify that the verb parameters specified satisfy the 
parameter values for the ACTIVATE_SESSION verb described in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


Select based on result of parameter verification: 
When an ABEND condition is identified 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) to abnormally 
terminate this instance of the transaction program (control is not returned). 
When a parameter error is identified 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 
When all parameters are correct 
Create an ACTIVATE_SESSION request record. 
Set RM_ACTIVATE_SESSION.TCB_ID to PS_PROCESS_DATA.TCB_ID to identify 
the transaction control block describing this instance of PS. 
Set RM_ACTIVATE_SESSION.LU_NAME to the LU name specified in the CNOS verb. 
Set RM_ACTIVATE_SESSION.MODE_NAME to the mode name specified in the CNOS verb. 
Send ACTIVATE_SESSION request to RM. 
Receive SESSION_ACTIVATED reply from RM. 
Set CNOS RETURN_CODE according to the return code in the 
SESSION_ACTIVATED reply received from RM. 
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DEACTIVATE_SESSION_PROC 


DEACTIVATE_SESSION_PROC 


FUNCTION: 


INPUT: 
OUTPUT: 


NOTE : 


This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues a DEACTIVATE_SESSION verb. It sends = an 
RM_DEACTIVATE_SESSION request to RM to activate a session. 

The CNOS DEACTIVATE_SESSION verb 


Request to RM (RM_DEACTIVATE_SESSION), RETURN_CODE of DEACTIVATE_SESSION verb 


This procedure has addressability to RM via PS_PROCESS DATA.LU_ID. 


Referenced procedures, FSMs, and data structures: 


RM page 3-18 
DEALLOCATION_CLEANUP_PROC page 5.0-13 
PS_ PROCESS DATA page 5.0-19 
RM_DEACTIVATE_SESSION page A-27 


Verify that the verb parameters specified satisfy the 
parameter values for the ACTIVATE_SESSION verb described in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 
If an ABEND condition is identified then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) 
to abnormally terminate this instance of the transaction program 
(control is not returned). 


Else 


Set the CNOS RETURN_CODE to OK. 
Create a DEACTIVATE_SESSION request record. 
Set RM_DEACTIVATE_SESSION.TCB_ID to PS_PROCESS DATA.TCB_ID to identify 
the transaction control block describing this instance of PS. 
Set RM_DEACTIVATE_SESSION.SESSION_ID to the SESSION_ID specified in the CNOS verb. 
Set RM_DEACTIVATE_SESSION.TYPE to the TYPE specified in the CNOS verb. 
Send DEACTIVATE_SESSION request to RM. 
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DEFINE_PROC 


5.4-38 


DEF INE_ PROC 


This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues any of the DEFINE verbs (DEFINE_LOCAL_LU, 
DEFINE_REMOTE_LU, DEFINE_MODE, or DEFINE_TP). It is used to initialize or 
modify attributes of the LUCB, PARTNER_LU, MODE, and TRANSACTION_PROGRAM data 
structures. 


The DEFINE verb parameters 


The attributes of the data structure are defined with the specified values 


This verb may be used to define any other attributes of the LU that are mean- 
ingful for a given implementation. 


Referenced procedures, FSMs, and data structures: 


LUCB page A-1 
PARTNER_LU page A-2 
MODE | page A-3 
TRANSACTION_PROGRAM page A-4 


Verify that the verb parameters specified satisfy the 
parameter values for the DEFINE verb ii) 


SNA Transaction Programmer's Reference Manual for LU Ivpe 6.2. 
If an ABEND condition is identified then 


Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) to abnormally 
terminate this instance of the transaction program (control is not returned). 


The parameters specified are all valid attributes of the LUCB, PART- 
NER_LU, MODE, or TRANSACTION_PROGRAM data structure. 


Assign values to the attributes of the data structure according to those 
specified on the DEFINE verb. 


Else 
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DISPLAY_PROC 


DISPLAY_PROC 


This procedure is called by PS_COPR, the control-operator-verb router, when a 
transaction program issues any of the DISPLAY verbs (DISPLAY_LOCAL_LU, DIS- 
PLAY_REMOTE_LU, DISPLAY_MODE, or DISPLAY_TP). It is used to display attri- 
butes of the LUCB, PARTNER_LU, MODE, and TRANSACTION_PROGRAM data structures. 


The DISPLAY verb parameters 
The specified attributes of the data structure are displayed for the user. 


This verb may be used to display any other attributes of the LU that are mean- 
ingful for a given implementation. 


Referenced procedures, FSMs, and data structures: 


LUCB page A-] 
PARTNER_LU page A-2 
MODE page A-3 
TRANSACTION_PROGRAM page A-4 


Verify that the verb parameters specified satisfy the 
parameter values for the DISPLAY verb in 


SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


If an ABEND condition is identified then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) to abnormally 
terminate this instance of the transaction program (control is not returned). 


Else 


Display the requested LUCB, PARTNER_LU, MODE, or TRANSACTION_PROGRAM 
attributes as they are currently defined. 


Chapter 5.4. Presentation Services--Control-Operator Verbs 54-39 


DELETE_PROC | 


DELETE_PROC 


FUNCTION: This procedure is called by PS_COPR, the control-operator-verb router, when a 
7 transaction program issues a DELETE verb. It is used to delete attributes of 
the LUCB, PARTNER_LU, MODE, and TRANSACTION_PROGRAM data structures. 
INPUT: The DELETE verb parameters 


OUTPUT: The data structure attributes are deleted 


NOTE: This verb may be used to delete any other attributes that are meaningful for a 
‘given implementation. | 


Referenced procedures, FSMs, and data structures: 


LUCB page A-1 
PARTNER_LU page A-2 
MODE page A-3 
TRANSACTION_PROGRAM . page A-4 


Verify that the verb parameters specified satisfy the 
parameter values for the DELETE verb in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


If an ABEND condition is identified then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) to abnormally 
terminate this instance of the transaction program (control is not returned). 


Else 


— 
The parameters specified are all valid attributes of the LUCB, PART- 
NER_LU, MODE, or TRANSACTION_PROGRAM data structure. 


Delete the LUCB, PARTNER_LU, MODE, or TRANSACTION_PROGRAM attributes 
as specified on the DELETE verb. 
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LOCAL_SESSION_LIMIT_PROC 
LOCAL_SESSION_LIMIT_PROC 


FUNCTION: This procedure is invoked by either of the following verb-specific CNOS proce- 
dures: INITIALIZE _SESSION_LIMIT, RESET_SESSION_LIMIT. It processes CNOS 
control-operator verbs that affect only the local LU: INITIALIZE. and 
RESET_SESSION_LIMIT for single-session connections and for mode name SNASVCMNG. 


INPUT: The CNOS source LU verb parameters from the calling procedure 


OUTPUT: Return code for the CNOS verb (CNOS RETURN_CODE) 


NOTE: This procedure read-locks the MODE for the entire procedure. 


Referenced procedures, FSMs, and data structures: 


LOCAL_VERB_PARAMETER_CHECK page 5.4-42 
SNASVCMG_VERB_PARAMETER_CHECK page 5.4-43 
CHANGE_ACTION page 5.4-44 
LUCB page A-l 


Using the LUCB, determine the type of session possible 
with the partner LU, either single or parallel. 


If the type of connection is single session then 
Call LOCAL_VERB_PARAMETER_CHECK (page 5.4-42), 
with the CNOS verb parameters, to verify the verb parameters. 


Else 
Call SNASVCMG_VERB_PARAMETER_CHECK (page 5.4-43), with the CNOS verb 
parameters, to perform the appropriate parameter checks. 


If the check found no errors then 
Call CHANGE_ACTION (page 5.4-44), with the CNOS verb parameters, 
to change the session limits at the source LU according to the parameters specified. 
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ne eee ore Gee ames eum 


LOCAL_VERB_PARAMETER_CHECK 


5.4-42 


LOCAL_VERB_PARAMETER_CHECK 


FUNCTION: . This procedure performs validity checks on a CNOS verb for single-session con- 
| nections, and it returns the CNOS-verb RETURN_CODE for.any error detected. 


INPUT: The CNOS source LU verb parameters, PARTNER_LU_LIST, and MODE_LIST 


OUTPUT: CNOS verb RETURN_CODE value 


Referenced procedures, FSMs, and data structures: 


DEALLOCATION_CLEANUP_PROC ; page 5.0-13 
LUCB page A-1 
PARTNER_LU page A-2 
MODE page A-3 


Verify that the specified verb parameters satisfy the single-session 
parameter values as described for this verb in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


Attributes of the mode are verified against fields in the appropriate 


MODE structure for the specified PARTNER_LU. | 


Select based on result of parameter verification: 
When all parameters are correct 
Set the CNOS RETURN_CODE to OK--AS_SPECIFIED. 
When an ABEND condition is identified 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) 
to abnormally terminate this instance of the transaction program 
(control is not returned). 


| A mode name value of ALL constitutes an ABEND condition when the CNOS 
verb is RESET_SESSION_LIMIT. 


When a parameter error 1s identified 
Set the CNOS RETURN_CODE for this verb to PARAMETER_ERROR. 

When the MODE.SESSION_LIMIT is not 0 
Set the CNOS RETURN_CODE to LU_MODE_SESSION_LIMIT_NOT_ZERO. 

When all (LU,MODE) session limits to this single session partner LU are currently 0 
and the sum of all (LU,MODE) session Limits to other partner LUs = the total 
session limit (in the LUCB) 

Set the CNOS RETURN_CODE for this verb to LU_SESSION_LIMIT_EXCEEDED. 
When the session limit specified exceeds the LOCAL_MAX_SESSION_LIMIT in the MODE 
Set the CNOS RETURN_CODE for this verb to REQUEST_EXCEEDS MAX_ALLOWED. 
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SNASVCMG_VERB_PARAMETER_CHECK 
SNASVCMG_VERB_PARAMETER_CHECK 


FUNCTION: This procedure performs validity checks ona CNOS verb for mode name 
SNASVCMG, and it returns the CNOS-verb RETURN_CODE for any error detected. 


INPUT: Transaction program verb parameters, PARTNER_LU_LIST, and MODE_LIST 


OUTPUT: CNOS verb RETURN_CODE value if any errors are detected, otherwise OK is 
returned 


Referenced procedures, FSMs, and data structures: 


DEALLOCATION_CLEANUP_ PROC page 5.0-13 
LUCB page A-l 
PARTNER_LU page A-2 
MODE page A-3 


Verify that the verb parameters specified satisfy the parameter values appropriate 
for parallel-session connections, as described in 


SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


Select, in order, based on result of parameter verification: 
When an ABEND condition is identified 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) 
to abnormally terminate this instance of the transaction program 
(control is returned). 
When a parameter error is identified 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 
When the MODE.SESSION_LIMIT is not 0 
Set the CNOS RETURN_CODE to LU_MODE_SESSION_LIMIT_NOT_ZERO. 
When the session limit specified could not be added without exceeding 
the session limit in the LUCB for the LU (page 5.4-4) 
Set the CNOS RETURN_CODE to LU_SESSION_LIMIT_EXCEEDED. 
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CHANGE_ACTION 


CHANGE_ACTION 


FUNCTION: 


INPUT: 


OUTPUT: 


NOTE : 


Referenced proc 


This procedure is called when the LU accepts a valid (and negotiated, if nec- 
essary) CNOS command. This procedure updates the (LU,mode) entries for 
affected mode names with the new session limit parameters. It decides wheth- 
er this LU is responsible for taking any action to change the session count, 
and if so, sends a CHANGE_SESSIONS request to RM. 


The CNOS verb parameters specified, if the CNOS verb is local to this LU only; 
the new session limit parameters in the CNOS reply record, if the CNOS action 
is distributed; the role of the LU to be modified (source or target), PART- 
NER_LU_LIST and MODE_LIST | 


Session limits and drain state are updated in the MODE; CHANGE_SESSIONS to RM 


_ This procedure locks the MODE for the entire procedure. 


See SNA Transaction Programmer's Reference Manual for LU Type 6.2 for the 
session-limit parameters affected by each CNOS verb. 


This procedure has addressability to RM via PS_PROCESS_DATA.LU_ID. 


edures, FSMs, and data structures: 


RM page 3-18 
CHANGE_SESSIONS | page A-26 
PARTNER_LU | - | page A-2 
MODE | page A-3 
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CHANGE_ACTION 


Select based on whether one MODE or all MODEs with the PARTNER_LU are affected 
(see the MODE_LIST associated with the PARTNER_LU): 
When only one MODE is affected 
Update the session-lLimit parameters for the specified (LU, mode) entry 
(MODE .SESSION_LIMIT, MODE.MIN_CONWINNERS LIMIT, MODE.MIN_CONLOSERS LIMIT; 
MODE .DRAIN_SELF, MODE.DRAIN_PARTNER, MODE.RESPONSIBLE) as they are applicable: 


For single-session mode names and for mode name SNASVCMG, the session limit 
parameters affected are those specified on the particular CNOS verb and the 
changes are reflected in the source LU only. 


MODE .MINCONWINNERS_LIMIT is set from MINCONWINNERS SOURCE specified in 
the CNOS = command. MODE .MINCONLOSERS_LIMIT is set from 


MINCONWINNERS_TARGET specified in the CNOS command. 


For parallel-session connections defined with the partner LU, the session Limit 
parameters affected are those specified on the CNOS reply and the changes are 
reflected as appropriate in both the source and the target LU (when this 
procedure is called from SOURCE_SESSION_LIMIT (or LOCAL_SESSION_LIMIT) and 
PROCESS_SESSION_LIMIT, respectively). 


At the source LU, MODE.MIN_CONWINNERS_LIMIT is set from 
MIN_CONWINNERS_SOURCE specified in the CNOS reply and 


MODE .MIN_CONLOSERS_ LIMIT is set from MIN_CONWINNERS TARGET specified 
in the CNOS reply. The reverse is true at the target LU. 


If the verb issued at the source LU is INITIALIZE_SESSION_LIMIT or CHANGE_SESSION_LIMIT, 
or, according to the responsible field of the CNOS reply (applicable only when the 
CNOS function is distributed), this LU is responsible for session deactivation then 


Create a CHANGE _SESSIONS request record. 

Set CHANGE_SESSIONS.TCB_ID to PS_PROCESS_DATA.TCB_ID to identify the transaction 
control block describing this instance of PS. 

Set CHANGE _SESSIONS.LU_NAME to PARTNER_LU.LOCAL_LU_NAME. 

Set CHANGE _SESSIONS.MODE_NAME to the affected mode name as specified on the 
CNOS verb. 

Set CHANGE_SESSIONS.DELTA to the difference between the LU_MODE_SESSION_LIMIT 
specified on the CNOS command or reply and the current MODE.SESSION_LIMIT. 

If the verb issued by the source LU is CHANGE_SESSION_LIMIT and the limit in the 
reply is less than the current session limit, or the verb issued by the source LU 
is the distributed function RESET_SESSION_LIMIT verb | MODE.DRAIN_SELF = NO then 

If the responsible field value in the CNOS reply specifies the current LU (which 
could be source or target) then 
Set CHANGE_SESSIONS.RESPONSIBLE to YES. 
Else 
Set CHANGE_SESSIONS.RESPONSIBLE to NO. 
Else (RESPONSIBLE value will not be significant to RM) 
Set CHANGE _SESSIONS.RESPONSIBLE to NO. 
Send the CHANGE_SESSIONS request to RM. 


When all MODEs are affected (in which case the verb issued by the source LU is 
RESET_SESSION_LIMIT } 
Do the following for each MODE (except SNASVCMG) with the PARTNER_LU 
Set MODE.DRAIN_SELF and MODE.DRAIN_PARTNER based on the current 
session limit and the drain parameters of the CNOS reply. 
Set SESSION_LIMIT, MIN_CONWINNERS LIMIT and MIN_CONLOSERS_LIMIT to 0. 
If this LU is responsible for session deactivation | MODE.DRAIN_SELF = NO then 
Create a CHANGE_SESSIONS request record as described in detail above. 
Send the CHANGE_SESSIONS request to RM. 
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SOURCE-LU CNOS PROCEDURES 


5 .4-46 


SOURCE_SESSION !IMI7_PROC 


rors my 


FUNCTION: 


INPUT: 


OUTPUT: 


Referenced 


proc 


SESSION_LIMIT_DATA_LOCK_MANAGER | 
VERB_PARAMETER_CHECK 


SOUR 
CHEC 


CHANGE_ACTION 


PART 
MODE 


This procedure is invoked by any of the following verb-specific CNOS proce- 
dures: INITIALIZE_SESSION_LIMIT, CHANGE_SESSION_LIMIT, RESET_SESSION_LIMIT. 
It provides common overall processing of a parallel-session CNOS 
control-operator verb issued by a source LU control operator transaction pro- 
gram. It invokes other procedures to check the verb parameters for validity, 
detect and resolve race conditions with any other CNOS transaction, build a 
command record, allocate a conversation with the target LU, exchange command 
and reply records with the target LU, update the PARTNER_LU_LIST and MODE_LIST 
with the new session limit parameters, and, if necessary, request the 
resources manager to activate or deactivate sessions. If errors are detected 
at any point, it skips subsequent steps and cleans up from previous steps. 
It passes a RETURN_CODE to the calling procedure indicating success or a 
failure reason. 


CNOS source LU verb parameters, from the calling procedure; the CNOS reply 
from the target LU, via SOURCE_CONVERSATION_CONTROL; the (LU,mode) entries 
with the session limits in the MODE, PARTNER_LU_LIST and MODE_LIST, and other 
CNOS parameters; the lock to control contention for the PARTNER_LU_LIST and 
MODE_LIST by CNOS transaction processes, and to resolve CNOS races (maintained 
by SESSION_LIMIT_DATA_LOCK_MANAGER ) 


Return code for the CNOS verb, CNOS RETURN_CODE; procedure SOURCE_CONVERSATION 
allocates and deallocates a conversation with the target LU and issues con- 
versation verbs; specified (LU,mode) entries updated via CHANGE_ACTION in the 
MODE; CHANGE_SESSIONS issued to RM—via CHANGE ACTION 


edures, FSMs, and data structures: 
page 5 
page 5 
CE_CONVERSATION_CONTROL page 5 
K_CNOS_REPLY page 5 
page 5 
page A 
page A 


NER_LU 
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SOURCE_SESSION_LIMIT_PROC 


Call VERB_PARAMETER_CHECK (page 5.4-48), 
with the verb parameters, to verify the syntax of the parameters. 


If all parameters are determined to be correct then 


Call SESSION_LIMIT_DATA_LOCK_MANAGER (page 5.4-67) 
to perform a source-LU lock on the affected (LU,mode) entry or entries 
and prevent simultaneous access by other CNOS transactions. 


Select based on one of the following conditions: 
When the state of the lock is changed from UNLOCKED to 
LOCKED_BY_SOURCE for each affected (LU,mode) entry 


MODE is now locked against any other CNOS transaction. 


Build a CNOS command record with the parzmeters spesificd sn the verb 
and consistent with the changea-number-of-sessions record 
(Appendix H). 


Tf tne command is change or initialize session limits then | 
If the MODE.SESSION_LIMIT < the new limit that 1s being proposed then 
Set MODE.CNOS_NEGOTIATION_IN_PROGRESS = TRUE. 
Set MODE.LIMIT_BEING_NEGOTIATED = LU_MODE_SESSION_LIMIT from verb. 
This is done so BINDs that arrive prior to the CNOS reply are not rejected. 


Do until the CHECK_CNOS_REPLY procedure does not return RETRY 


| The verb completes or a permanent error occurs. | 


Call SOURCE_CONVERSATION_CONTROL (page 5.4-49); 
with the CNOS command, to send on the conversation and to receive the CNOS reply. 


If the SOURCE_CONVERSATION_CONTROL returns OK (a CNOS reply was 
successfully received) then 
Optionally, perform syntax checking on the CNOS reply record 
according to the description in Appendix H. 


If the CNOS reply is syntactically correct, or the syntax 
check was not performed then 
Call CHECK_CNOS_REPLY with the CNOS reply record and the 
fully-qualified LU names for the source and target LUs 
to determine the result of the negotiation (page 5.4-56). 


Else 
Set the CNOS RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 


If the session limits were successfully accepted or negotiated then 
Call CHANGE_ACTION (page 5.4-44), with the CNOS reply, 
to update the limits in the MODE structure for the source LU and notify RM. 


| If the command is change or initialize session limits then 
| Set MODE.CNOS_NEGOTIATION_IN PROGRESS = FALSE. 
Call SESSION_LIMIT_DATA_LOCK_MANAGER (page 5.4-67) 
to perform the unlock operation on the affected (LU,mode) entry or entries. 


When the lock operation performed on any of the affected (LU,mode) entries 
was other than a state change from UNLOCKED to LOCKED_BY_SOURCE 
(because of a previous lock operation performed for a different CNOS command) 
Set the CNOS RETURN_CODE to COMMAND_RACE_REJECT. 


When the mode name 1s not found for the PARTNER_LU 
Set the CNOS RETURN_CODE to PARAMETER_ERROR. 
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VERB_ PARAMETER. a aka 


5.4-48 


VERB_ PARAMETER CHECK 


This procedure performs validity checks on the CNOS verb issued by the 
_ control-operator transaction program at the source LU, and it returns the 
“S-.* €NOS-verb RETURN_ CODE for any error detected. 


Parameters from transaction program verb, PARTNER_ LU_LLIST and MODE_LIST 


CNOS verb RETURN_CODE value if any errors are detected; othernise, OK is 
returned | 


This procedure locks the MODE for the entire ‘procedure. 


Referenced procedures, FSMs, and data structures: 


_ DEALLOCATION_ CLEANUP_PROC | | page 5.0-13 
Luce a: page A-] 
PARTNER_ Lu . s 3 | page A-2 
MODE | , page A~3 


Verify that the specified verb parameters satisfy the parameter values as 


described for this verb in SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


Select based on result of parameter verification: 
When all parameters are correct 
Set the CNOS RETURN_CODE for this verb to OK--AS_SPECIFIED. 
When an ABEND error condition is identified 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) 
to abnormally terminate this instance of the transaction program 
(control is not returned). 
When a parameter error is identified 
Set the CNOS RETURN_CODE to PARAMETER_ ERROR. 
When the verb issued is INITIALIZE _SESSION. LIMIT and the MODE. SESSION_ LIMIT 
is not 0 for the affected MODE at the PARTNER_LU 
Set the CNOS RETURN_CODE to LU_. MODE _SESSION_LIMIT_NOT_ZERO. 
When the verb issued is CHANGE_SESSION_LIMIT and the MODE.SESSION_LIMIT 
is 0 for the affected MODE at the PARTNER_LU | 
Set the CNOS RETURN_CODE to LU_MODE_SESSION_LIMIT_ZERO. | 
When the specified session limit could not be added without exceeding 
the session limit in the LUCB for the LU (page 5.4-4). 
Set the CNOS RETURN_CODE to LU_SESSION_LIMIT_EXCEEDED. 
When the specified session limit could not be added without exceeding 
the LOCAL_MAX_SESSION_LIMIT in the MODE 
Set the CNOS RETURN_CODE to REQUEST _EXCEEDS_MAX_ALLOWED. 
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SOURCE_CONVERSATION_CONTROL 
SOURCE_CONVERSATION_CONTROL 


FUNCTION: This procedure controls a conversation with the target LU to send the CNOS 
command and receive the CNOS reply. It controls the selection of mode name 
for the conversation. In the event of session outage, it retries the conver- 
sation either until it succeeds or until no sessions are active for any mode 
name affected by the CNOS verb. 


INPUT : CNOS verb parameters including the name ee the target LU; CNOS command; Summa- 
ry of the success or failure of the CNOS exchange across’ the conversation 
(provided by the SOURCE_CONVERSATION procedure) so this routine can make a 


retry decision: 


¢ OK: conversation completed successfully 

e SON: session outage occurred; retry for the same mode name might succeed 

e NO_SESSION: no session is available for this mode name; retry for another 
mode name might succeed 

@e FAILED: conversation or transaction failure; retry is not likely to suc- 
ceed 


OUTPUT: CNOS replys summary of outcome of conversation for caller 


Referenced procedures, FSMs, and data structures: 


SOURCE_CONVERSATION page 5.4-50 
LUCB page A-1l 
PARTNER_LU page A-2 
MODE page A-3 


Do until the SOURCE_CONVERSATION procedure returns a value 
OK or FAILED, or if all possible modes are tried but no sessions 
are available on any of these 


Choose a mode name with which to allocate a conversation. The mode 
name is optionally selected from an implementation-defined List 
(if any of these sessions is immediately available) or the SNA- 
defined mode name SNASVCMG. 

Choose the RETURN_CONTROL value for the ALLOCATE verb 
(see SNA Transaction Programmer's Reference Manual for LU Type 6.2). 


Initially, choose mode names from the implementation defined list and 
use a RETURN_CONTROL value of IMMEDIATE. Ance thece have been 
exhausted, try the SNA-defined mode (SNASVCMG) with a RETURN_CONTROL 


value of WHEN_SESSION_ALLOCATED. If this is not successful, choose a 
mode name from chose that will be affected by this CNOS command and 
usa @ RETURN_CONTROL value of WHEN_SESSION_ALLOCATED. 


Call SOURCE_CONVERSATION (page 5.4-50) with the parameters 

chosen above and the CNOS command record. SOURCE_CONVERSATION will issue 

the basic conversation verbs to send the CNOS command, receive the CNOS 

reply over the conversation and obtain the fully-qualified LU names for this and the 
partner LU for later comparison. 


If SON (session outage notification) is returned, the conversation is 
retried on another session for the same mode name. 


Set the return value for this routine to the value returned from 
SOURCE_CONVERSATION. 
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SOURCE_CONVERSATION 


SOURCE_CONVERSATION 


FUNCTION: This procedure conducts a conversation with the target LU to send the CNOS 
7 command and receive the CNOS reply. It issues the conversation verbs. It 
invokes other routines to analyze the return codes to determine when and how 

to deallocate the conversation and whether retry is necessary. 


LU name of the partner, mode name for the conversation on which = the 
CHANGE_NUMBER_OF_SESSIONS command and reply records are exchanged; the 
RETURN_CONTROL parameter for the ALLOCATE verb; CNOS command 


OUTPUT: CNOS reply; summary of the success or failure of a particular basic conversa- 
tion verb, according to the particular RESULT_CHECK_* procedure called: 


e 6.0K: «conversation completed successfully | 

e SON: session outage occurred; retry for the same mode name might succeed 

e NO_SESSION: no session is available for this mode name; retry for another 
mode name might succeed 

® FAILED: conversation or transaction failure; retry 1s not likely to suc- 
ceed | : 


The SOURCE_CONVERSATION_CONTROL procedure will make a retry decision based on 
this information. . | 


See SNA Transaction Programmer's Reference Manual for LU Type 6.2 for conver- 
sation verbs. 


Referenced procedures, FSMs, and data structures: 


RESULT_CHECK_ALLOCATE page 5.4-52 
RESULT_CHECK_SEND_COMMAND page 5.4-53 
RESULT_CHECK_RECEIVE_REPLY page 5.4-54 
RESULT_CHECK_RECEIVE DEALLOCATE page 5.4-55 
LUCB page A~-1 
PARTNER_LU page A-2 


Conduct a conversation with the partner. 


Issue the ALLOCATE verb according to the mode name and RETURN_CONTROL values 
passed to this procedure and default values as described on page 5.4-27. 

Call RESULT_CHECK_ALLOCATE to examine the RETURN_CODE value from the ALLOCATE 
(according to the RETURN_CONTROL value specified on the verb) and DEALLOCATE the 
conversation if appropriate (page 5.4-52). 
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SOURCE_CONVERSATION 


If the ALLOCATE verb returned OK then 
Issue a GET_ATTRIBUTES verb, with the RESOURCE parameter returned 
from the ALLOCATE, to obtain the fully qualified LU names for 
this LU and the partner LU. 


Issue a SEND_DATA verb to send the CNOS command. 

Call RESULT_CHECK_SEND_COMMAND (page 5.4-53) to examine 
the parameters returned from the SEND_DATA verb and perform the DEALLOCATE 
if appropriate. 


If the SEND_DATA verb returned OK then 
Issue a RECEIVE_AND_WAIT verb to receive the CNOS reply. 
Call RESULT_CHECK_RECEIVE_REPLY (page 5.4-54) to examine 
the parameters returned from the RECEIVE_AND_WAIT verb and perform the DEALLOCATE 
if appropriate. 


If the RECEIVE_AND_WAIT verb returned OK then 
Issue the RECEIVE_AND_WAIT verb to receive the DEALLOCATE from the 
partner LU. 
Call RESULT_CHECK_RECEIVE_DEALLOCATE (page 5.4-55) to examine 
the parameters returned from the RECEIVE_AND_WAIT verb and perform the DEALLOCATE 
if appropriate. 


Set the return code for this procedure from the value returned by the last 
RESULT_CHECK_® procedure called. 
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RESULT_CHECK_ALLOCATE 


FUNCTION: This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the ALLOCATE verb that allocates the CNOS conversation, and it clas- 
sifies the outcome for use in later decisions, specifically whether to retry, 
quit, or continue. For some error conditions, the conversation will need to 
be deallocated. 


INPUT: RETURN_CODE, RETURN_CONTROL 
OUTPUT: Summary of the success or failure of the ALLOCATE verb: 


® OK: conversation completed successfully 

e SON: session outage occurred; retry for the same mode name might succeed 

® WNO_SESSION: no session is available for this mode name; retry for another 
mode name might succeed 

@ FAILED: conversation or transaction failure; retry is not likely to suc- 
ceed 


This information will be used by SOURCE_CONVERSATION_CONTROL to make a retry 
decision. 


Checks are required unless designated optional. 


Select based on the RETURN_CONTROL value specified on the ALLOCATE verb: 
When IMMEDIATE (implementation-selected mode name) 


Select based on the RETURN_CODE value from the ALLOCATE verb: 
When OK 
Return OK to the SOURCE_CONVERSATION procedure. 
When ALLOCATION_ERROR (optional check) 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate 
the conversation locally. 
Return FAILED to the SOURCE _CONVERSATION procedure. 
When UNSUCCESSFUL (no session is immediately available) 
Return NO_SESSION to the SOURCE_CONVERSATION procedure. 
Otherwise (optional check) 
Return FAILED to the SOURCE_CONVERSATION procedure. 


When WHEN_SESSION_ALLOCATED 


Select based on the RETURN_CODE value from the ALLOCATE verb: 

When OK 

Return OK to the SOURCE_CONVERSATION procedure. 
When ALLOCATION_ERROR--ALLOCATION_FAILURE_RETRY . 

Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 

conversation locally. 

Return NO_SESSION to the SOURCE_CONVERSATION procedure. 
Otherwise (optional check) . 

Return FAILED to the SOURCE_CONVERSATION procedure. 
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RESULT_CHECK_SEND_COMMAND 
RESULT_CHECK_SEND_COMMAND 


FUNCTION: This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the SEND_DATA verb that sends the CNOS command, and it classifies 
the outcome for use in later decisions, specifically whether to retry, quit, 
or continue. For some error conditions, the conversation may need to be deal- 


located. 
INPUT: RETURN_CODE, REQUEST_TO_SEND_RECEIVED 
OUTPUT: Summary of the success or failure of the SEND_DATA verb: 


® OK: conversation completed successfully 

e SON: session outage occurred; retry for the same mode name might succeed 

® NO_SESSION: no session is available for this mode name; retry for another 
mode name might succeed 


® FAILED: conversation or transaction failures retry ts not likely to suc- 
ceed 


This information will later be used by SOURCE_CONVERSATION_CONTROL to make a 
retry decision. 


NOTE : Checks are required unless designated optional. 


If the REQUEST_TO_SEND_RECEIVED parameter returned from the SEND_DATA verb is NO then 


Select, in order, based on the RETURN_CODE parameter from the SEND_DATA verb: 
When OK 


Return OK to the SOURCE_CONVERSATION procedure. 
When RESOURCE_FAILURE_ RETRY 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation 
locally. 
Return SON (session outage notification) to the SOURCE CONVERSATION procedure. 


When ALLOCATION_ERROR--SECURITY_NOT_VALID, 
ALLOCATION_ERROR~-~-TP_NOT_AVAILABLE_NO_RETRY;, 
or ALLOCATION _ERROR--TP_NOT_AVAILABLE_RETRY 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 
conversation locally. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
When ALLOCATION_ERROR--* (optionally check for any other variety of ALLOCATION_ERROR) 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 
conversation locally. 
Return FAILED to the SOURCE_CONVERSATION procedure. 


When DEALLOCATE_ABEND_PROG 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation 
locally. 


Return FAILED to the SOURCE_CONVERSATION procedure. 
Otherwise 


Yssue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the 
conversation. 


Return FAILED to the SOURCE _CONVERSATION procedure. 


Else 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
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RESULT_CHECK_RECEIVE_REPLY 


FUNCTION: This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the RECEIVE _AND_WAIT verb that receives the CNOS reply, and it clas- 
sifies the outcome for use in later decisions, specifically whether to retry, 
quit, or continue. For some error conditions, the conversation may need to be 


deallocated. 
INPUT: RETURN_CODE, REQUEST_TO_SENT_RECEIVED, WHAT_RECEIVED 
OUTPUT: Summarv of the success or failure of the RECEIVE_AND_WAIT verb: 


¢ OK: conversation completed successfully 

e SON: session outage occurreau; retry for the same mode name might succeed 

® NO_SESSION: no session is available for this mode name; retry for another 
mode name might succeed 

® FAILED: conversation or transaction failure; retry is not likely to suc- 
ceed 


This information will later be used by SOURCE_CONVERSATION_CONTROL to make a 
retry decision. 7 


NOTE: Checks are required unless designated optional. 


If the REQUEST_TO_SEND_RECEIVED parameter from the RECEIVE_AND_WAIT verb is NO then 


Select based on the RETURN_CODE value returned from the 
RECEIVE_AND_WAIT verb: 
When OK 
If the WHAT_RECEIVED parameter returned is DATA_COMPLETE then 
Return OK to the SOURCE_CONVERSATION procedure. 


Else 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the 
conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 


When RESOURCE_FAILURE_RETRY 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 
conversation locally. 
Return SON (session outage notification) to the SOURCE_CONVERSATION procedure. 


When ALLOCATION_ERROR--SECURITY_NOT_VALID, 
ALLOCATION_ERROR--TP_NOT_AVAILABLE_NO_RETRY; 
or ALLOCATION_ERROR--TP_NOT_AVAILABLE_RETRY 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 
conversation locally. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
When ALLOCATION_ERROR--* 
(optionally check for any other variety of ALLOCATION_ERROR) 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 
conversation locally. 
Return FAILED to the SOURCE_CONVERSATION procedure. 


When DEALLOCATE_NORMAL or DEALLOCATE_ABEND_PROG (optional check) 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 
conversation locally. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
Otherwise 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the 
conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 


Else 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the 
conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
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RESULT_CHECK_RECEIVE_DEALLOCATE 


FUNCTION: This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the RECEIVE_AND_WAIT verb that receives DEALLOCATE from the target 
LU, and it classifies the outcome for use in later decisions, specifically 
whether to retry, quit, or continue. For some error conditions, the conversa- 
tion may need to be deallocated. 


INPUT : RETURN_CODE, REQUEST_TO_SEND_RECEIVED, WHAT_RECEIVED (used only for error log) 
OUTPUT: Summary of the success or failure of the RECEIVE_IMMEDIATE verb: 


e OK: conversation completed successfully 

® SON: session outage occurred; retry on the same mode name might succeed 

®e NO_SESSION: no session is available for this mode name; retry on another 
mode name might succeed 

® FAILED: conversation or transaction failure; retry is not likely to suc- 
ceed 


If the REQUEST_TO_SEND_RECEIVED parameter returned from the DEALLOCATE verb is NO then 


Select based on the RETURN_CODE value returned from the DEALLOCATE verb: 
When DEALLOCATE_NORMAL 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation locally. 
Return OK to the SOURCE_CONVERSATION procedure. 
When RESOURCE_FAILURE_RETRY 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation 
locally. 
Return SON (session outage notification) to the SOURCE_CONVERSATION procedure. 
When DEALLOCATE_ABEND_PROG 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the conversation peeeery! 
Return FAILED to the SOURCE_CONVERSATION procedure. 
Otherwise 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 


Else 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the conversation. 
Return FAILED to the SOURCE_CONVERSATION procedure. 
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CHECK_CNOS_REPLY 


This procedure is called when the conversation with the target LU completes. 
It determines whetker the conversation mist be retried due to a double-failure 
race condition, whether the verb must be terminated due to error, or whether 
to continue with the action phase of CNOS processing. 


It performs optional receive checks on the validity of the reply. It sets the 
return code for the CNOS verb. 


Fields of the CNOS reply record, PARTNER_LU_LIST and MODE_LIST for current 
session limit OUTPUT.CNOS RETURN_CODE, if any errors are found; RETRY, used by 
caller to select subsequent processing 


Checks are required unless designated optional. 


Referenced procedures, FSMs, and data structures: | Be ae | 
LUCB page A-1 


PARTNER_LU | e page A-2 
MODE - SF page A-3 _ 


Select based on the reply modifier field of the CNOS reply record: 
When the reply modifier is MODE_NAME_NOT_RECOGNIZED 
Set the CNOS RETURN_CODE to UNRECOGNIZED. MODE NAME. — 
When the reply modifier indicates an (LU,mode) session limit of 0 
Verify that, for the PARTNER_LU MODEs specified on the original CNOS varies 
that the SESSION_LIMIT=0, and DRAIN_SELF=NO. 


If these MODE attributes are correctly verified then 
Set the CNOS RETURN_CODE to LU MODE_ SESSION_ LIMIT_ CLOSED. 


Else 
Set the CNOS RETURN_CODE to RESOURCE_ FATLURE_ NO_ RETRY. 
When the reply modifier is COMMAND _RACE_ DETECTED 

Check the state of the lock to determine whether the race is a single- or 
double-failure race (page 5.4-30). 

Compare the fully-qualified LU names for the source and target LUs 
(returned from the GET_ATTRIBUTES verb in the SOURCE CONVERSATION 
procedure) with respect to the EBCDIC collating sequence (page 5.4-14)}. 


If the race detected is a single-failure race or the LU name of the target 
LU is greater by the above comparison then 
Set the CNOS RETURN_CODE to COMMAND_RACE_REJECT. 


Else (double-failure race condition and source LU name is greater) 
Return RETRY to SOURCE_SESSION_LIMIT_PROC. 
When the reply modifier is ACCEPTED 
Set the CNOS RETURN_CODE to OK-~-AS_ SPECIFIED. 
When the reply modifier is NEGOTIATED 
Optionally verify that the parameters in the CNOS reply were correctly 
negotiated, according to page 5.4-28. 


If the reply parameters were successfully verified or the optional 
checks were not implemented then 
Set the CNOS RETURN_CODE to OK--AS_NEGOTIATED. 


Else 
Set the CNOS RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
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TARGET-LU CNOS PROCEDURES 


X06F 1 


FUNCTION: This procedure is the CNOS service transaction program at the target LU. It 
is invoked by PS_INITIALIZE as a result of an FMH-5 Attach header being 
received from the source LU. It issues the PROCESS _SESSION_LIMIT control 
operator verb to activate CNOS processing at the target LU. It informs the 
target-LU operator of the CNOS action. 


OUTPUT: Issues control-operator verb PROCESS _SESSION_LIMIT 


NOTE: See SNA Transaction Programmer's Reference Manual for LU Type 6.2 
control-operator verbs. 


Issue the PROCESS_SESSION_LIMIT verb to be processed by PS_COPR. 
(page 5.4-32) and inform the target-LU operator of the 
resulting CNOS RETURN_CODE. 


The algorithm to inform the operator is implementation dependent. 
This algorithm may make use of DEFINE or DISPLAY control-operator 


verbs to determine the current session Limits, in the MODE, and then 
display them on the operator console. 
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- PROCESS_SESSION_LIMIT_PROC 


FUNCTION: This procedure is invoked by PS_COPR, the control-operator-verb router, when 
the CNOS service transaction program at the target LU issues a PROC- 
ESS_SESSION_LIMIT control-operator verb. This procedure directs overall proc- 
essing of CHANGE_NUMBER_OF_SESSIONS at the target LU. This procedure receives 
the CNOS command from the source LU and sends the CNOS reply. It invokes TAR- 
GET_CONVERSATION to issue the conversation verbs and process the return codes. 


It invokes other procedures to check the verb and the conversation attributes 
for validity, detect and resolve race conditions with any other CNOS trans- 
action, negotiate CNOS parameters, update the affected MODEs with the new ses- 
sion limit parameters, and, if necessary, request the resources manager to 
activate or deactivate sessions. If errors are detected at any point, it 
skips subsequent steps and cleans up from previous steps. It passes a 
RETURN_CODE to the calling procedure in the PROCESS _SESSION_LIMIT record indi- 
cating success or a failure reason. If an ABEND condition occurs, it calls PS 
to abnormally terminate the transaction-program process. 


INPUT: PROCESS _SESSION_LIMIT verb, CNOS command from the source LU via the conversa- 
tion; PARTNER_LU_LIST and MODE_LIST 


OUTPUT: Outcome of the operation to the caller in PROCESS_SESSION_LIMIT (RETURN_CODE); 
CNOS reply sent to the source LU via the conversation; updated MODE entries 
via CHANGE_ACTION; CHANGE _SESSIONS record to RM, via CHANGE_ACTION; SES- 
SION_LIMIT_DATA lock tested, set, and reset via SES- 
SION_LIMIT_DATA_LOCK_MANAGER — 


Referenced procedures, FSMs, and data structures: 


CHECK_CNOS_COMMAND | page 5.4-63 
CHANGE_ACTION page 5.4-44 
TARGET_COMMAND_CONVERSATION : page 5.4-60 
TARGET_REPLY_CONVERSATION . page 5.4-65 
SESSION_LIMIT_DATA_LOCK_MANAGER page 5.4-67 
DEALLOCATION_CLEANUP_ PROC | page 5.0-13 
~LUCB | | page A-1l 
PARTNER_LU page A-2 
MODE : page A-3 
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PROCESS_SESSION_LIMIT_PROC 


Check the verb parameters to detect ABEND conditions as described in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2 for this verb. 


If either of the ABEND conditions exists then 
Call DEALLOCATION_CLEANUP_PROC (page 5.0-13) to abnormally 
terminate this instance of the transaction program (control 1s not returned). 


Else 
Call TARGET_COMMAND_CONVERSATION (page 5.4-60) 
with the resource ID of the conversation with the partner LU to receive 
the CNOS command from the source LU. 
If an error occurs before the CNOS command can be successfully received then 
Set the CNOS RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 


Else 
Call SESSION_LIMIT_DATA_LOCK_MANAGER to perform a target-LU lock 
on the appropriate (LU,mode) entry or entries to prevent 
simultaneous access by other CNOS transactions (page 5.4-67). 
Optionally, perform syntax checking on the CNOS command record according 
to the description in Appendix H. 


Select, in order, based on the values of fields in the CNOS command: 
When syntax errors are identified 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate the 
conversation. 
When the MODEs specified on the CNOS command cannot be found 
in the list of MODEs for the PARTNER_LU | 
Set the reply modifier field for the CNOS reply to MODE_NAME_NOT_RECOGNIZED. 
When the MODEs specified on the CNOS command have SESSION_LIMIT=0, and 
DRAIN_SELF=NO then 
The LU may refuse to accept the command by returning an abnormal reply 
modifier field specifying an (LU,mode) session limit of 0 
(this is implementation defined). 
Otherwise 


Select based on result of SESSION_LIMIT_DATA_LOCK_MANAGER: 
When the state of the LOCKs have changed from UNLOCKED 
to LOCKED_BY_TARGET 
Call CHECK_CNOS_COMMAND (page 5.4-63), with the CNOS command, 
to perform optional receive checks (if errors are found, 
the conversation is deallocated). 
If the checks were not performed or no errors were detected then 
Call NEGOTIATE_REPLY (page 5.4-64), with the CNOS command 
record, in order to generate the negotiated values of the 
CNOS parameters. 
Otherwise (if any LOCK has been rejected) 
Set the reply modifier field for the CNOS reply to COMMAND_RACE_DETECTED. 


[f the conversation has not been deallocated then 
Build the CNOS reply record consistent with the original CNOS command, the reply modifier 
field reflecting the identified errors, and the negotiated CNOS limits, as 
appropriate (see Appendix H). 
Call TARGET_REPLY_CONVERSATION (page 5.4-65) 
with the CNOS reply record to be sent to the source LU. 


If the CNOS reply is successfully sent across the conversation then 
Set the CNOS RETURN_CODE for the PROCESS_SESSION_LIMIT verb according 
to the modifier field of the CNOS reply. 
If the reply modifier field indicates that the CNOS limits were either ACCEPTED 
or NEGOTIATED then 
Call CHANGE_ACTION (page 5.4-44) with the CNOS reply record 
to change the session limits at the target LU. 


Else 
Set the CNOS RETURN_CODE to RESOURCE_FAILURE_NO_RETRY. 
Call SESSION_LIMIT_DATA_LOCK MANAGER (page 5.4-67) to UNLOCK the affected 
(LU,mode) entry or entries. 


Chapte~ 53.4. Presentation Services--Control-Operator Verbs 5.4-59 


TARGET_COMMAND_CONVERSATION 


TARGET_COMMAND_CONVERSATION 


FUNCTION: This procedure checks the attaching conversation for validity and returns the 
partner LU name to the caller. If the conversation is valid, this procedure 
receives the CNOS command from the source LU. If an error 1s detected, it 
terminates the conversation with DEALLOCATE TYPE(ABEND_PROG). | 


INPUT: Resource ID of the conversation with the partner (source) LU, conversation 
attributes via GET_ATTRIBUTES 


OUTPUT: Partner LU name, from conversation via GET_ATTRIBUTES; CNOS command, from the 
source LU via the conversation; 


NOTE : See SNA Transaction Programmer's Reference Manual for LU Type 6.2 for conver- 
sation verbs. 


Referenced procedures, FSMs, and data structures: 


RESULT_CHECK_RECEIVE_COMMAND page 5.4-61 
RESULT_CHECK_RECEIVE_SEND page 5.4-62 
RESULT_CHECK_SEND_REPLY page 5.4-66 


Issue a GET_TYPE verb (according to the input parameters provided) to verify that the 
type of conversation 1s BASIC. 
Issue a GET_ATTRIBUTES verb (according to the input parameters provided) to verify 
that the connection type is parallel sessions and that the SYNC_LEVEL 
is NONE (optional receive check). 


The GET_ATTRIBUTES verb returns the name of the source LU. The target then uses 


this information to determine the type of sessions possible with the source LU as 
a conversation partner. 


If the above conversation attributes are not verified to be correct then 
(optional check ) 

Issue a DEALLOCATE verb with TYPE=ABEND_PROG and return from this procedure. 
The LOG_DATA parameter of the DEALLOCATE verb, if used, is supplied by the 
implementation. For its format, see ERROR LOG GDS VARIABLE in 
"Appendix H. FM Header and LU Services Commands". 


Else 


Issue a RECEIVE_AND_WAIT verb to receive the CNOS command. 
Call RESULT_CHECK_RECEIVE_COMMAND to examine the parameters returned and perform 
the DEALLOCATE, if appropriate (page 5.4-61). 


If RESULT_CHECK_RECEIVE_COMMAND returns OK then | 
Issue a RECEIVE_AND_WAIT verb to receive the SEND indicator. 
Call RESULT_CHECK_RECEIVE_SEND to examine the parameters returned and perform 
the DEALLOCATE, if appropriate (page 5.4-62). If RESULT_CHECK_RECEIVE_SEND 
returns OK, the CNOS command was successfully received. 
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RESULT_CHECK_RECEIVE_COMMAND 
RESULT_CHECK_RECEIVE_COMMAND 


This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the RECEIVE AND _WAIT verb that receives the CNOS command; it deter- 
mines whether to issue DEALLOCATE, and what TYPE to specify. 


RETURN_CODE, REQUEST_TO_SENO_RECEIVED, WHAT_RECEIVED 


Checks are required unless designated optional. 


If the REQUEST_TO_SEND_RECEIVED parameter returned from the 
RECEIVE _AND_WAIT verb is NO then 


Select based on the RETURN_CODE parameter returned from 
RECEIVE_AND_WAIT: 
When OK 
If WHAT_RECEIVED = DATA_COMPLETE then 
Return OK to TARGET COMMAND CONVERSATION. 


Else (optional check) 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to 
deallocate the conversation. 
When RESOURCE _FAILURE_RETRY, DEALLOCATE_NORMAL or 
DEALLOCATE_ABEND_PROG (optional check) 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate 
the conversation locally. 
When RESOURCE _FAILURE_NO_RETRY 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to 
deallocate the conversation. 
Gtherwise (optional check ) 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to 
deallocate the conversation. 


Else (REQUEST_TO_SEND_RECEIVED=YES--an optional check) 


Issue a DEALLOCATE verb with TYPE=ABEND_PROG to 
deallocate the conversation. 
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- RESULT_CHECK_RECEIVE_SEND 


This procedure analyzes the RETURN_CODE and other significant returned parame- 
ters from the RECEIVE_AND_WAIT verb that receives SEND; it determines whether 
to issue DEALLOCATE, and what TYPE to speci fy. 


RETURN_CODE, REQUEST_TO_SEND_RECEIVED, WHAT_RECEIVED 


Checks are required wless designated optional. 


If the REQUEST_TO_SEND_RECEIVED parameter returned from the RECEIVE AND WAIT 
is NO then 


Select based on the RETURN_CODE parameter returned from the RECEIVE _AND_ WAIT: 
When OK 
If WHAT_RECEIVED = SEND then 
Return OK to TARGET_COMMANOD_CONVERSATION. 
Else ; 
Issue a DEALLOCATE verb with TYPE=ABEND_ PROG to deallocate 
the conversation. 
When RESOURCE FAILURE RETRY, DEALLOCATE_NORMAL, or 
DEALLOCATE_ABEND_PROG (optional check) 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 
conversation locally. 
Otherwise 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate 
the conversation. 


Else 


Issue a DEALLOCATE verb with TYPE=ABEND_PROG to deallocate 
the conversation. 
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CHECK_CNOS_COMMAND 


This procedure performs receive checks at the target LU on the CNOS command 


received from the source LU. If errors are detected, DEALLOCATE ABEND 
replaces a CNOS reply. 


CNOS command parameters 


Checks are required unless designated optional. 


Referenced procedures, FSMs, and data structures: 


page A-1 
PARTNER_LU page A-2 
MODE page A-3 


Optionally check the verb parameters, encoded as fields in the 
CNOS command, for ABEND conditions as described in 


SNA Iransaction Programmer's Reference Manual for LU Type 6.2. 


Since the session limits of the SNA-defined mode name, SNASVCMG, may 


not be changed, a mode name of SNASVCMG in the CNOS command consti- 
tutes another ABEND condition. 


Some parameter checks may require knowledge of mode attributes that 


currently exist. For these, see the appropriate MODE structure for 
the specified PARTNER_LU. 


If any ABEND condition is identified then 
Issue a DEALLOCATE verb with TYPE=ABEND_PROG 
to deallocate the conversation. 
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NEGOTIATE_REPLY 


This procedure generates the negotiated values of the CNOS limits for the CNOS 
reply» including the reply modifier field. 


This procedure assumes that the session liwsit parameters in the command are 
valid. 


Source-LU specified CNOS verb parameters, PARTNER_LU_LIST, and MODE_LIST 


Session limit parameters for reply 


This procedure does not change the CNOS limits in the MODE. 


Referenced procedures, FSMs, and data structures: 


CLOSE_ONE_REPLY page 5.4-65 
PARTNER_LU page A-2 
MODE page A-3 


If the CNOS verb issued at the source LU is INITIALIZE_SESSION_LIMIT 
or CHANGE_SESSION_LIMIT (when the action field of ahe CNOS command is SET) then 
Negotiate the LU_MODE_SESSION_LIMIT, MIN_CONWINNERS SOURCE, 
and MIN_CONWINNERS TARGET parameters (as described in 
SNA Transaction Programmer's Reference Manual for LU Iype 6.2) according to 
an implementation-dependent algoritha. 
If any of the session limits are going to be less than the current 
limits, RESPONSIBLE may also be negotiated from TARGET to SOURCE. 


Else (RESET_SESSION_LIMIT verb) | 
If the command affects only one MODE at the PARTNER_LU then 
Call CLOSE_ONE_REPLY (page 5.4-65) 


with the CNOS command record to build the CNOS reply record. 
Else (all mode names affected) 
For MODE_NAME(ALL)», only RESPONSIBLE may be negotiated. 


Negotiate the RESPONSIBLE parameter from TARGET to 
SOURCE. 


If any of these parameters is negotiated then 
Set the reply modifier field of the CNOS reply to NEGOTIATED. 


Else 
Set the reply modifier field of the CNOS reply to ACCEPTED. 
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CLOSE_ONE_REPLY 


This procedure builds the target-LU's reply whenever the verb issued at the 
source LU is RESET_SESSION_LIMIT Caction field of the CNOS command is CLOSE) 
and only one mode name is affected. It optionally sets the reply-modi fier 
field of the CNOS reply to MODE_NAME_CLOSED if there is an error in 
DRAIN_ SOURCE. 


LU_NAME of partner LU; MODE, for current state of CNOS parameters; CNOS com- 
mand parameters. 


Updated reply modifier and negotiated parameters 


Referenced procedures, FSMs, and data structures: 
PARTNER_LU page A-~2 


MODE page A-3 


Create the CNOS reply according to the negotiation rules described on 
page 5.4-28 (when the action field in the CNOS command 

is CLOSE and only one mode name is affected) and the description of 

the DRAIN and RESPONSIBLE parameters of the RESET_SESSION_LIMITS verb in 
SNA Transaction Programmer's Reference Manual for LU Type 6.2. 


If the current session limit is 0, the drain for the source LU 
(MODE.DRAIN_ PARTNER) is set to NO and the command = specifies 
DRAIN_SOURCE( YES), the target LU may either issue a DEALLOCATE with 
TYPE=ABEND or send a CNOS reply with the MODIFIER field specifying an 
(LU,mode) session limit of 0. 


This condition occurs only when there is a design error in the source 
LU such that this ABEND condition is not recognized and the command is 
forwarded to the target LU. 


TARGET_REPLY_CONVERSATION 


This procedure sends the CNOS reply. 


Resource ID of the conversation with the partner (source) LU, the 
change-number-of-sessions record, in this case, a CNOS replys 


Outcome of conversation (reply and DEALLOCATE NORMAL sent; DEALLOCATE ABEND 
sent or DEALLOCATE received) 


See SNA Transaction Programmer's Reference Manual for LU Iype 6.2 for conver- 
sation verbs. 


Referenced procedures, FSMs, and data structures: 
RESULT_CHECK_SEND_REPLY page 5.4-66 


Issue a SEND_DATA verb (with the resource ID of the attaching conversation) 
to send the CNOS reply to the source LU. 


Call RESULT_CHECK_SEND_REPLY (page 5.4-66) to examine 


the parameters returned on the verb and perform a DEALLOCATE of the conversation, 
if appropriate. 
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RESULT_CHECK_SEND_REPLY 


RESULT_CHECK_SEND_REPLY 


FUNCTION: 
ters from the SEND_DATA verb that sends the CNOS reply, and 


whether to issue DEALLOCATE, and what TYPE to specify. 


RETURN_CODE, REQUEST_TO_SEND_RECEIVED 


If the REQUEST_TO_SEND_RECEIVED parameter returned from the SEND_DATA 
verb is NO then 


Select based on the RETURN_CODE parameter returned from the SEND_DATA verb: 


When OK 
Issue a DEALLOCATE verb with TYPE=SYNC_LEVEL to deallocate 


the conversation normally. 
When RESOURCE_FAILURE_RETRY or DEALLOCATE_ABEND_PROG 
Issue a DEALLOCATE verb with TYPE=LOCAL to deallocate the 


conversation locally. 


When RESOURCE_FAILURE_NO_RETRY | 
Issue a DEALLOCATE verb with TYPE= ABEND_ PROG +: “deallocate 


the conversation. 


Otherwise 
Issue a DEALLOCATE van with | TYPE=ABEND_ PROG to deallocate 


the conversation. 


Else 
Issue a DEALLOCATE verb with TYPE=ABEND_ PROG to deallocate 


the conversation. 
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This procedure analyzes the RETURN_CODE and other significant returned parame- 


it determines 


SESSION_LIMIT_DATA_LOCK_MANAGER 
SESSION_LIMIT_DATA_LOCK_MANAGER 


FUNCTION: This procedure determines whether the specified MODEs exist, and if so, sets 
er resets the session-limit-data lock in the MODE entry to prevent simultane- 
ous access by another CNOS transaction initiated at this or the partner LU. 


The operation to be performed, identification of whether source or target LU 
issued the request, partner LU name and mode mame, PARTNER_LU_LIST, and 
MODE_LIST 


The state of the lock in affected MODE entries is updated 


This procedure locks the MODE. 


Referenced procedures, FSMs, and data structures: 


LUCB page A-1 
PARTNER_LU page A-2 
MODE page A-3 


Select based on the requested locking operation: 


When LOCK 
Change the state of the lock (or locks) as described on page 5.4-30. 


The four resulting lock states depend upon their previous lock 

state (if applicable) and the input that caused the transition to that state. 
For any input operation and current lock state combination not explicitly 
described, the state of the lock does not change. 


If the CNOS command affects all MODEs for the PARTNER_LU 

then the lock is to be placed on all affected (LU,mode) entries. 

If any of the affected (LU,mode) entries has been previously 
LOCKED_BY_SOURCE, LOCK_DENIED is set for that mode name, 

but the others are left unlocked. 

When UNLOCK 

The state of the (LU,mode)-entry lock can be changed to the UNLOCK state 
only when the UNLOCK is attempted by the transaction program at the LU 
that currently has the entry locked. 


Note that, in the LOCK_DENIED state, the transaction program at the 
source LU has the lock on the (LU,mode) entry. 


If the CNOS command affects ALL MODEs, the UNLOCK is performed for all 
affected (LU,mode) entries. 
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CHAPTER 6.0. HALF-SESSION 


GENERAL DESCRIPTION 


LU Network Services (LNS) 


Resource 


| ane eNO 


Router 


Initializer => 


s Manager (RM) 


A 
, A 
Presentation Services (PS) 


A 


Data Flow Control (DFC) 


Half-session (HS) 


V 


Path Control (PC) 


Figure 6.0-1. Overview of Half-Session 


The half-session component (see Figure 6.0-1) 
resides in the LU and represents a session 
with another LU or with a control point 
(e.g.» an SSCP). The half-session's primary 
function is to control the data traffic flow 
for a session. It also performs initializa- 
tion when activated and, when necessary, 
causes itself to be deactivated. 


The components of the half-session are an 
initializer, a router, data flow control 
(DFC--see "Chapter 6.1. Data Flow Control"), 
and transmission control (TC--see "Chapter 
6.2. Transmission Control"). The initializer 
records information from the session acti- 
vation request (e.g., BIND) for later use by 


DFC and TC. The router distributes message 
units to DFC and TC. Message units received 
from LU network services (LNS--see "Chapter 
G4. LU Network Services"), resources manager 
(RM--see "Chapter 3. LU Resources Manager"), 
and presentation services (PS--see "Chapter 
5.0. Overview of Presentation Services") are 
routed to DFC. Message units received from 
path control (PC) are routed to TC. The pri- 
mary functions of DFC are to translate 
between BIUs and records produced from trans- 
action program verbs and to control the flow 
of data between the half-session and PS, RM, 
and LNS. The primary function of TC is to 
control the flow of data between the 
half-session and path control. 
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The LU half-session is created by LNS when a 
session-activation request (BIND or ACTLU) 
has been  successtully processed. The 
half-session is destroyed by LNS when (1) a 
session-deactivation request (UNBIND or 
DACTLU) has been processed, (2) a session 
route outage has occurred, or (3) a control 
point session has been deactivated and 
requires a heirarchical reset of all related 
sessions (e.g., the PU-CP session has been 
deactivated). | 


The half-session, RM, PS, LNS, and PC are all 
separate processes. Message units are sent 


PROTOCOL BOUNDARIES BETWEEN HS AND OTHER COMPONENTS 


Message units that flow from HS to RM: 


to HS by RM, PS, LNS, and PC. When a message 
unit arrives, HS may receive and process it. 
Another message unit cannot be received by HS 
until the current one is completely proc- 
essed. 


HS can selectively receive from these proc- 
esses; e.g.» when HS is waiting for a 
required reply or response from the partner 
HS, HS may elect to ignore messages from PS 
and process messages from only RM, LNS, and 
PC. - 


Message units that flow from RM to HS: 


ATTACH_HEADER 
BID 

BID_RSP 
FREE_SESSION 
BIS_RQ 
BIS_REPLY 
RTR_RQ 

RTR_RSP 
SECURITY_HEADER 


Message units that flow from HS to PS: 


Message units that flow from HS to LNS: 


Message units that flow from HS to PC: 
PIU information containing a request 


6.0-2 


RECEIVE_DATA 
CONFIRMED 
RECEIVE_ERROR 
REQUEST_TO_SEND 
RSP_TO_REQUEST_TO_SEND 


INIT_HS_RSP 

Network services BIUs 
(carried in HS_RCV_RECORD) 

ABORT_HS 


or response BIU 


BID_WITHOUT_ATTACH 
BID_WITH_ATTACH 
BID_RSP 
YIELD_SESSION 
BIS_RQ 

BIS_REPLY 

RTR_RQ 

RTR_RSP 
HS_PS_CONNECTED 
ENCIPHERED_RD2 


Message units that flow from PS to HS: 


SEND_DATA_RECORD 
CONFIRMED 
SEND_ERROR 
REQUEST_TO_SEND 


Message units that flow from LNS to HS: 


INIT_HS 


Network services BIUs 


(carried in HS_SEND_RECORD) 


Message units that flow from PC to HS: 
PIU information containing a request 


or response BIU 
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FORMAL DESCRIPTION 


HS 


FUNCTION: This procedure causes the half-session to be initialized and invokes the 
appropriate router according to the type of half-session (LU-CP or LU-LU). 


INPUT: At creation time, HS_ID (half-session identifier) and LU_ID (LU identifier); 
at run time, INIT_HS received from LNS 


OUTPUT: INIT_HS_RSP sent to LNS, HS_ID and LU_ID recorded for other procedures in the 
half-session. The following are recorded for use by other procedures in the 
half-session: LOCAL.SENSE_CODE is initialized to 0; the PC_ID of the path 
control that the half-session uses; the half-session role (PRI or SEC)3 and 
the FM and TS profile types. 


Referenced procedures, FSMs, and data structures: 


TC. INITIALIZE page 6.2-8 
DFC_INITIALIZE page 6.1-18 
PROCESS LU_LU_ SESSION paye 6.0-4 
PROCESS _CP_LU_SESSION page 6.0-5 
INIT_HS page A-16 
INIT_HS_RSP page A-11 
LOCAL page 6.0-6 


Before the half-session can begin processing, it must be initialized. 
Therefore, the first thing HS does after creation is to receive an 
initialization record (INIT_HS) from LNS. The initialization record 
specifies the rules and parameters that this session will use (this 
information comes from BIND or ACTLU). 


Record the HS_ID and LU_ID to make the information available to all 
half-session procedures. 


Set LOCAL.SENSE_CODE to 0 (the no error state). 

From INIT_HS.TYPE, record an indication that this half-session is 
primary (PRI) or secondary (SEC). 

Depending on whether the INIT_HS.DATA_TYPE = ACTLU_IMAGE or BIND_IMAGE, 
record the FM profile and TS profile types from the ACTLU or BIND image. 


Initialize the half-session by calling 
TC.INITIALIZECINIT_HS record) (page 6.2-8) and 
DFC_INITIALIZE(INIT_HS record) (page 6.1-18), passing them 
the INIT_HS record. 


If TC and DFC initialization is successful then 
Send a positive INIT_HS_RSP to LNS (use 0 for the SENSE_CODE; POS for TYPE; 
and HS_ID to identify this HS). 
If FM profile is 0 or 6 (CP-LU session) then 
Call PROCESS _CP_LU_SESSION (page 6.0-5). 
Else (FM profile is 19, for an LU-LU session) 
Call PROCESS_LU_LU_SESSION (page 6.0-4). 


Else (initialization unsuccessful--LOCAL.SENSE_CODE indicates the type of error) 
Send a negative INIT_HS_RSP to LNS for this LU. Use 
LOCAL.SENSE_CODE as the INIT_HS_RSP sense code, NEG for TYPE> 
and HS_ID to identify this HS. 


Wait to be destroyed. 
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PROCESS LU _LU_SESSION 


6.0-4 


PROCESS_LU_LU_SESSION 


FUNCTION: 


INPUT: 


OUTPUT: 


| 


Does processing for LU-LU half-session (FM profile 19). Message units 
received from RM and PS are routed to DFC. Message units received from PC are 
routed to TC. The LU-LU half-session continues to operate until an error con- 
dition occurs or the half-session process is destroyed. If an error condition 
eccurs, LOCAL.SENSE_CODE is set (by DFC or TC) with the sense data indicating 
what Kind of error occurred. When this field is set, the half-session sends 
an ABORT message to LNS. This causes LNS to send an UNBIND(protocol error) 
for this LU-LU session. 


Message units received from PS, RM, and PC; LOCAL.SENSE_CODE 


ABORT_HS sent to LNS if error 


Referenced procedures, FSMs, and data structures: 


DFC_SEND_FROM_RM page 6.1-20 
DFC_SEND_FROM_PS page 6.1-19 
TRY_TO_RCV_ SIGNAL page 6.1-22 
TC.RCV page 6.2-15 
TC.TRY_TO_SEND_IPR page 6.2-19 
FSM_BSM_FMP19 page 6.1-43 
FSM_CHAIN SEND_FMP19 page 6.1-46 
ABORT_HS page A-l1 
LOCAL page 6.0-6 


Do while LOCAL.SENSE_CODE = 6. (Do while no errors.) 
Select based on the source of the record: 
When the record is from PS 
Call DFC_SEND_FROM_PS (page 6.1-19) to route the record to DFC. 


(When the session is between brackets 

[state of FSM_BSM_FMP19 = BETB] or PS is sending data and the 
half-session is expecting either a response or a reply 

(state of FSM_CHAIN_SEND_FMP19 = PEND_RSP or PENO_RCV_REPLY], 
processing of request records from PS is deferred until 

this condition is resolved. ) 


When the record is from RM 
Call DFC_SEND_FROM_RM (page 6.1-20) to route the record to OFC. 


When the record is from PC 
Call TC.RCV (page 6.2-15) to route the record to TC, 


The input to those procedures is the received record. 
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PROCESS_LU_LU_SESSION 


If LOCAL.SENSE_CODE # 6 (error found) then 
Send an ABORT_HS record to LNS. The ABORT_HS.SENSE_CODE comes from 
LOCAL.SENSE_CODE; ABORT_HS.HS_ID is the HS_ID saved during HS initialization. 
(LNS sends an UNBIND. ) 


Else (no error found--continue processing) 
Call TRY_TO_RCV_SIGNAL (page 6.1-22) to 
try to process a queued SIGNAL request. Whether or not a queued SIGNAL 
request is processed depends on the state of the half-session. 
The state of the half-session may change each time a record is 
received and processed; therefore, the TRY_TO_RCV_SIGNAL 
procedure is called after each record so that it can check 
the current half-session state and process a SIGNAL request if necessary. 


Call TC.TRY_TO_SEND_IPR (page 6.2-19) to 

see if an ISOLATED PACING RESPONSE (IPR) may be sent, depending 

on the pacing state of the half-session. The TC.TRY_TO_SEND_IPR 
procedure is called so that it can check the current half-session 
pacing state and send an IPR if necessary. 

(The formal description sends IPRs even if a response 

will be the next RU sent. Implementations may optimize flows 

by setting the Pacing indicator to PAC on the response, rather than 
sending an IPR followed by a response that has the pacing 

indicator set to ~PAC.) 


PROCESS_CP_LU_SESSION 


Does processing for CP-LU half-session (FM profiles 0 and 6). Message wits 
received from LLNS are routed to OFC. Message units received from PC are 
routed to TC. The CP-LU half-session continues to operate until the 
half-session process is destroyed (e.g.,» because of a DACTLU request). 


If an error condition occurs, LOCAL.SENSE_CODE is set with the sense data 
indicating the kind of error, the half-session component detecting the error 
sends a -RSP or logs the error. The CP-LU half-sesston continues to operate. 


Message units received from LNS and PC; FM profile type 


LOCAL. SENSE_CODE 


Referenced procedures, FSMs, and data structures: 


DFC_SEND_FROM_LNS page 6.1-22 
TC .RCV page 6.2-15 
FSM_IMMEDIATE_RQ_ MODE_SENO page 6.1-48 
LOCAL page 6.0-6 


Do until HS process is destroyed. 
Set LOCAL.SENSE_CODE to 0. 
Select based on the source of the record: 
When the record is from LNS 
Call DFC_SENO_FROM_LNS (page 6.1-22) to route the record to DFC. 
(When the session is using immediate request mode [FM profile = 0] 
and a request is already outstanding UFSM_IMMEDIATE_RQ_MODE_SEND 
(page 6.1-48) is in the PEND_RSP state], processing of 
request records from LNS is deferred until a response to the outstanding 
request is received. ) 


When the record is from PC 
Call TC.RCV (page 6.2-15) to route the record to TC. 
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DATA STRUCTURES 


LOCAL 


This is the definition of the process data used by the half-session. This data 
accessed by any procedure in the half-session process. 


LOCAL 
COMMON: fields shared by all HS components 
SENSE_CODE 


DFC: fields used only by DFC 
LU_LLU: fields used for LU-LU sessions (FM profile 19) 

SQN_SEND_CNT: contains SNF (see page 6.0-6) 

PHS_BB_REGISTER: contains SNF (see page 6.0-6) 

SHS_BB_REGISTER: contains SNF (see page 6.0-6) 

CURRENT_BRACKET_SQN: contains SNF (see page 6.0-6) 

SEND_ERROR_RSP_STATE: possible values: RESET, NEG_OWED (negative 
response owed) 

SIG_RECEIVED: possible values: YES, NO 

SEND_BUFFER: buffer area for collecting transaction program data until 
the maximum RU size is reached or DFC 1s instructed to send the data. 

TC: fields used only by TC 
TCCB 

Q_PAC: the outbound pacing queue for send pacing. Holds BIUs 

that were not sent earlier because the send pacing count 

was 0. They are now waiting for a pacing response to 

let the next pacing group (window) be sent. 

SEND_PACING_COUNT: the number of requests that the local 
half-session can send before having to wait for a 

‘pacing response (varies between 2n-1 and 0, where n is the 

send window size) 

RCV_PACING_COUNT: the number of requests that the local 
half-session can yet receive from the partner half-session 

in the currently allowed windows (varies between 2n-1 and 0; 

where nis the receive window size). 

If a request is received when this count is 0, 

the request is refused with a negative response. 

SQN_RCV_CNT: the last received sequence number on the normal flow. 
Wraps to zero after 65535. 


Defines sequence number field. 


SNF: a 16-bit sequence number field. 
SQN: a 16-bit sequence number whose value wraps to 0 after 65535. 
BRACKET_STARTED_BY: possible values are PRI (1) or SEC (0). 
The high-order bit of the sequence number field is set when the bracket is started 
by the primary half-session and reset when the bracket is started by the secondary 
half-session. This 1s done so that sequence numbers on BB requests are iniauve. 


mn 


NUMBER: a 15-bit sequence number whose value wraps to 2 waiter 32767. 
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CHAPTER 6 


-1. DATA FLOW CONTROL 


INTRODUCTION 


The basic function of data flow control (DFC) 
component 18 to control the flow of data 
between half-sessions. DFC and FMD RUs flow 
through the data flow control component; net- 
work control and session control RUs do not. 
An LU may have a session with another LU or a 
control point (CP). The protocol rules 
(e.g.» FM profile) to be used on the session 
are established when the session is activated 
and differ based on the type of session. 


DFC FOR LU-LU HALF-SESSIONS 


OVERVIEW OF DFC FUNCTIONS 


The following functions are done by DFC for 
LU-LU sessions: 


e Request/Response Formatting: DFC 
enforces correct RH parameter settings 
for FMD and DFC requests and responses. 


@ Chaining Protocol: Chaining is a means 
of sending or receiving a group of RUs 
for which there will be at most one 
response. DFC enforces the chaining pro- 
tocol. 


DFC corre- 
with their associated 


® Request/Response Correlation: 
lates responses 
requests. 


¢  Request/Response Mode Protocols: Immedi- 
ate request and immediate response modes 
are enforced by DFC. 


® Send/Receive Mode Protocols: The 
normal-flow send/receive mode 
(half-duplex flip-flop) specifies a par- 
ticular form of coordination between 
sending and receiving of normal-flow 
requests and responses. 

® Bracket Protocols: Bracket protocols 


provide a means of sending or receiving a 
sequence of chains as a delimited trans- 
action entity. 


° Purging: When a bracket error negative 
response is sent for an incoming begin 
bracket (BB) chain, the remainder of that 
chain is purged. 


LU-LU sessions use FM profile 19; CP-LU ses- 
Sions use FM profile 0 or 6. Data flow con- 
trol protocols differ significantly based on 
the FM profile. Protocols associated with FM 
profile 19 contain many more functions and 
capabilities then those associated with FM 
profile 0 or 6. The following describes the 
data flow control protocols for LU-LU and 
CP-LU sessions. 


DFC STRUCTURE 


The DFC structure is shown in Figure 6.1-1 on 
page 6.1-2. 


The DFC initialization procedure is called by 
the half-session router (see "Chapter 6.0. 
Half-Session'') at the activation of each ses- 
sion. It initializes FSMs and other protocol 
related parameters to be used during the ses- 
sion. 


Send 


The DFC send procedures receive records from 
presentation services (PS) and from the 
resources manager (RM). They also receive 
records from the DFC receive procedure. The 
send procedures process the records and send 
them on to transmission control (TC). The 
send processing consists of creating corre- 
sponding BIU records and updating the states 
of DFC send FSMs. 


Receive 


The DFC receive procedure (DFC_RCV) receives 
BIU records from TC, processes them, and 
sends them on to PS or RM. It also generates 
BIU records that it sends to the DFC send 
procedures. DFC_RCV optionally checks the 
BIU records for receive error conditions. 
These are conditions that occur only when the 
other half-session has violated the architec- 
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Presentation Services (PS) 


Resources Manager (RM) 


DFC_ 
INITIALIZATION 
(Note) 


DFC_SEND 
(Note) 


<—— > 


V 


Transmission Control (TC) 


A 


DFC_RCV 


DFC 


Note: Called by half-session router ("Chapter 6.0. Half-Session") 


Figure 6.1-1. 


6.1-2 


ture. When DFC_RCV detects an error condi- 
tion, it sets the sense code (in global 
process data) and returns to the half-session 
router. The router will then cause the 
half-session to be deactivated. If no 
receive errors are detected, the processing 
consists mainly of updating the states of DFC 
receive FSMs and creating corresponding 
records to be sent on to PS or RM. 


Termination 


DFC and other half-session components stay 
active until a deactivation request (UNBIND 
or DACTLU) flows. On LU-LU sessions, DFC 
causes an UNBIND to be sent when an error is 
detected. See Chapter 6.0. 


PROTOCOL BOUNDARIES 


DFC sends, receives, and processes records. 
The records DFC sends to and receives from RM 
and PS represent commands and replies unique 
to DFC's protocol boundaries with RM and PS. 
DFC maps the commands and replies it receives 
from RM and PS into BIU records suitable for 
its processing; similarly, it maps BIU 
records into commands and replies suitable 
for processing by RM and PS. The records DFC 
sends to, and receives from, TC are BIU 
records that represent RU chains. 


The protocol boundary information (records 
exchanged) is summarized in Figure 6.1-2 on 
page 6.1-3. The detailed specifications of 
the protocol boundaries with PS, RM, and TC 
appear in the individual DFC procedures. 


Overview of DFC for LU-LU Half-Sessions 


Throughout this chapter, references to 
request units (requests) and response units 
(responses) pertain to the BIU records that 
represent the requests and responses. Refer- 
ences to the sending or receiving of requests 
and responses pertain to the protocol bounda- 
ry with TC, unless stated otherwise. 


FUNCTION MANAGEMENT PROFILE 19 


FM profiles are used to convey information 
about the protocols used on a session. FM 
profile 19 is used for LU-LU half-sessions. 
The DFC requests for this profile are BIS, 
LUSTAT, RTR» and SIG. These requests are 
used to control the flow of data between the 


half-e7ssions and are described in “DFC 
Request and Response Descriptions" on page 
6.1-14. 


The FM usage settings in BIND are as follows: 


e Chaining use (primary and = secondary): 
multiple RU chains. 


° Request control mode selection (primary 
and secondary): immediate. 


° Form of response requested (primary and 
secondary): RQE or RQD. 


indicator (primary and sec- 
no compression. 


® Compression 
ondary): 


e Send CEB 
ary): 


indicator (primary and second- 
either end may send CEB. 
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A 
SEND_DATA_RECORD 
SEND_ERROR 


RECEIVE_DATA 
CONFIRMED 
RECEIVE ERROR 


REQUEST_TO_SEND 8 REQUEST_TO_SEND 
BID_WITHOUT_ATTACH |BID_RSP ATTACH_HEADER RSP_TO_REQUEST_TO_SEND 
BID_WITH_ATTACH RTR_RSP FREE_SESSION 
HS_PS CONNECTED HS_PS_CONNECTED BID 
BIS_RQ BID_RSP 
BIS_REPLY RTR_RQ 
YIELD_SESSION RTR_RSP 
RTR_RQ BIS_RQ 
ENCIPHERED_RD2 BIS_REPLY 


SECURITY_HEADER 


DFC_SEND_ 
FROM_PS 


V | 
DFC_SEND_ DFC_RCV_FSMS 
FROM_RM 


(Note) (Note) A A 
+RSP( LUSTAT, BB) NORM_RQ | 
LUSTAT LUSTAT,BB,RQD] -RSP( BB) NORM_RSP 
FMD LUSTAT,CEB,RQE1 +RSPC(RTR) RSP( SIG) TRY_TO_RCV_ 
SIG FMD ,ATTACH,BB ~RSP( 0846 ) SIGNAL (Note) 
+RSP(RQD2|3) BIS "REQUEST" +RSP(CEB,RQD1 ) : 
-RSP( 0846 ) BIS "REPLY" 
RTR | — | 
FMD »SECURITY — LOG 
A 
Ge A 
V V V . 
+RSP( SIG) : 
[reser ee 


Note: Called by half-session router ("Chapter 6.0. Half-Session"') 


Figure 6.1-2. Detailed Structure and Protocol Boundaries of DFC for LU-LU Half-Sessions 


} @ FM header usage: FM headers (only FMH-5 ® Recovery responsibility: symmetric. 
| [Attach], FMH-7 [Error Description] and ® Contention winner/loser: primary 
| FMH-12 [Security]) are used. half-session (BIND sender) or secondary 
half-session (BIND receiver). The state 
e Brackets: brackets are used and the is negotiated at BIND time. This deter- 
reset state is in-brackets. mines who is bidder (contention loser) 
and who is first speaker (contention win- 
e Bracket termination rule: conditional | ner). 
termination. 


e Half-duplex flip-flop reset states: BIND 
e Alternate Code Set Allowed indicator: sender is in send state after RSP(BIND). 
may or may not be used. 
More detail of FM usage settings, and the 
¢ Normal-flow send/receive mode: formats and protocols implied by them, may be 
half-duplex flip-flop. found in the following pages. 
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USAGE ASSOCIATED WITH FM PROFILE 19 
Conditional End Bracket (CEB) 


The Conditional End Bracket (CEB) is used to 
indicate bracket termination. It is allowed 
only on an RH with EC. The bracket is terwi- 
nated in all cases except that a -RSP to a 
(CEB,RQD2|[3) chain leaves the session 
in-bracket (INB). The bracket terminates in 
all other circumstances. (See "Bracket Pro- 
tocols" on page 6.1-9 for more details on 
bracket termination. ) 


FM Header Usage 


The Format indicator (FI) in the RH is used 
to indicate the presence of an FM header as 
the first byte of FM data following this RH. 
The FM headers that are indicated by the FI 
are either FMH-5( Attach), FMH-7( Error 
Description), or FMH-12(Security); see 'Ap- 
pendix H. FM Header and LU Services Commands" 
for details. 


The FMH-S( Attach) may be carried in an RU 
with the Begin Chain indicator (BCI) set to 
BC. It may also be sent with BCI set to -BC 
when it is sent in an RU immediately follow- 
ing an FMH-12 that mwas (~EC,~CEB). 


The FMH-7(Error Description) may appear in 
any RU in a chain at any time during the life 
of a bracket; it may be followed by data 
Ci.e., it does not terminate the chain) or it 
may terminate a chain. The FMH-7 is not 
related to or bound by the chain state; it 
may be sent in ai (BC,-EC), (-BC,-~EC), 
(-BC,EC), or (BC,EC) request. 


The FMH-12(Security) may flow only as the 
first RU after the session is initiated. If 
cryptography is in effect, the FMH-12 flows 
after the CRV exchange is complete. . FMH-12 
is always sent in a (BC,RQE1) request. The 
request may indicate either (EC,CEB) or 
(-EC,-CEB); the latter is used when the next 
request carries an FMH-5 with ~-BC. 


Usage of DRI 


DR1 is sent in a positive response to an RQDI 
request in order to indicate that the 
requested function has been performed. The 
following are the only uses of DR1 in +RSP. 


1. When the sender of Attach elects to bid 
for the session without sending = an 
Attach, it may do so with an (RQD1,BB) 
LUSTAT(0006). The receiver sends the 
+DR1 when the session has been "allo- 
cated’ to the sender. The only request 
that may follow this sequence is an 
FMH-S( Attach) to attach a transaction 
program or LUSTAT with (RQE1,CEB) to can- 
cel the bid. (See “Chapter 3. LU 
Resources Manager" for more details on 
bidding. ) 


2. When RTR flows. (RTR is always sent 
RQD1.) 
3. When (RQ01,BB,CEB, Attach, data...) is 


received, i.e.» a Bid with data. 


4. When (RQD1,CEB) is received as a result 
of the remote transaction program issuing 
the DEALLOCATE verb with the ABEND 
option. 


5. When (RQD1,CEB) is received at sequence 
numbering wrap points, as part of the 
stray SIGNAL and stray response logic 
(see "Stray SIGNALs and Responses" on 
page 6.1-5). 


Sending RGE with BB from Contention Loser 


The contention loser is allowed to send 
(RQE*,BB,CD,FMH-5,data) as a Bid. 


Usage of LUSTAT(0006) (ROE) CEB) 
LU-LU sessions are activated in the 


in-brackets (INB) state. If, for some rea- 
son, RM decides a newly activated session is 
not needed, it sends YIELD SESSION to DFC. 
This results in an (RQE1,CEB) LUSTAT( 0006) 
being sent to terminate the unused bracket. 


Usage of SIGNAL(00010001) 


PS issues the REQUEST_TO_SEND command to DFC 
when the conversation is in receive state, 
requesting that the conversation be placed in 
send state (see "Send/Receive Mode Protocols" 
on page 6.1-10). SIGNAL always uses the code 
Request to Send (X'OGOLO0001L'). OFC then 
sends SIGNAL to the other half~-session. When 
+RSP(SIG) is received, OFC passes the 
RSP_TO_REQUEST_TO_SEND reply up to PS. The 
conversation enters the send state when an R 

carrying CD is received. 


Sequence Numbering of Requests and Responses 


DFC assigns sequence numbers to DFC and FMD 
requests and responses, as follows: 


e For normal-flow requests, the send 
sequence number count is incremented by 1 
and then assigned to the request. 


¢ A normal-flow BB response is assigned the 
sequence number of the corresponding 8B 
request. The high-order bit 1s 0 if the 
bracket was started by. the secondary 
half-session, or 1 if the bracket was 
started by the primary half-session. 


®e SIGNAL (the only = expedited-flow DFC 
request) and all responses are assigned 
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Sending Receiving 
Sequence Sequence 
Number Number LUa LUb 
(Note 1) BINO——--————---+__-__-__--—— > 
(Note 2) < RSPC BIND ) 
(Note 1) a cncenennermnncmeenn” FY, > 
(Note 2) ———aearememrenenereneanaenenrmarearncscmmenmnnnnene SA ( CRV ) 
1 (Note 3) [————————Normal-flow RU ———————_—___——_> 
(Note 4) < RSP(Normal-flow RU)————- 
2 Normal-flow RU > 
(Note 4) < RSP(Normal-flow RU)——— 
3 Normal-flomw RU > 
(Note 4) I< RSP(Normal-flow RU)———— 
(Note 4) < SIGNAL 
(Note 4) RSP( SIGNAL ) > 
4 Normal-flow RU ——————————_ > 
(Note 4) < RSP(Normal-flow RU)———— 
(Note 1) UNBIND > 
(Note 2) < RSP( UNBIND ) 
(Note 1) BIND > 
(Note 2) < RSP( BIND ) 
l Normal-flow RU ————-—————_> 
(Note 4) < RSP(Normal-flow RU)——— 
2 Normal-flow RU ————--——————> 
(Note 4) < RSP(Normal-flow RU)———— 
3 Normal-flow RU ————————_——_> 
(Note 4) < RSP(Normal-flow RU)———— 
® 
® 
@ 
Notes 


1. The sequence number in this case is an identifier, shich can have any value 0-65535. 


2. The sequence number in this case is an identifier, which has the same value as the request. 


3. The first normal-flow RU following the BIND begins the first bracket. 
bracket for efficiency. 


1. 


The session comes up in 


The bracket sequence number is 6, the sequence number of the first RU is 
After the first bracket is ended, subsequent brackets begin with a BB request. 


The bracket 


sequence number is the sequence number that flowed on the BB request. 


4. The sequence number in this case is an identifier, which has the following properties: 


Figure 6 


Figure 6.1-3 


The low-order 15 bits are the same as the low-order 15 bits of the sequence number that 


started the bracket. 


The high-order bit is 0 if the bracket was started by the secondary half-session, or 1 if the 
bracket was started by the primary half-session. 


° 1-3. 


Use of Sequence Numbers 


the sequence nuwber of the current brack- 


et. 


A rnormal-flow RTR response 


is assigned 


the sequence number of the corresponding 
RTR request. 


illustrates an example of the 
use of sequence numbers. 


In this figure, 


some session control RUs (BIND, UNBIND, and 


CRV) are also illustrated. 


Stray SIGNALS and Responses 


When a 


(RQD*,CEB) 


request 


sent 


(RQE1,CEB) or 


a stray SIGNAL or response can 


eccur. This is a SIGNAL or response that is 
received outside the bracket it is intended 
for, and which could be disruptive if not 
eliminated or not recognized as a stray. 
SIGNALS received outside the intended (cur- 
rent) bracket may be “early” or "late." 
“Early" SIGNALs are those received in a 
bracket that was started prior to the current 
bracket. "Late’’ SIGNALs are those recetved 
in a bracket that was started after the cur- 
rent bracket. Responses received outside the 


current bracket are always "late." Examples 
are shomm in the following figures. 
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SIGNAL or -RSP 


RQE1,CEB 


Bracket B gets the SIGNAL intended for A. 


Figure 6.1-4. Case 1: “Late” SIGNAL or 
Response 


RQE1,CEB 


RQE*,BB,CD 


Bracket A gets the SIGNAL intended for B. 


Figure 6.1-5. Case 2: "Early" SIGNAL 


RQD*,QR,CEB 


+RSP,QR 


RQE*,BB,CD 


Bracket A gets SIGNAL intended for B. 


Figure 6.1-6. Case 3: “Early" SIGNAL 


The following subsections discuss how prob- 


lems with strays are avoided. 


SENDING SIGNAL AND RESPONSES: Each LU elimi- 
nates problems with stray SIGNALs and stray 
responses by keeping three 16-bit "bracket 
ID" registers, a l-bit switch, and a 15-bit 
normal-flow request counter: 


© PHS _BB_REGISTER 


Bit 0: i 

Bits 1-15: Low-order 15 bits of TH 
sequence number of last 6B 
request sent by lor received 
from) primary half-session 
(PHS ) 


¢  SHS_BB_REGISTER 


Bit 0: 0 

Bits 1-15: Low-order 15 bits of TH 
sequence number of last BB 
request sent by (or received 
from) secondary half-session 
(SHS) 


® CURRENT_BRACKET_SQN 


Bit 0: 1 = Bracket started by PHS 
0 = Bracket started by SHS 
Bits 1-15: Low-order 15 bits of TH 
sequence rmmer of current 
bracket 


® An indication that a definite response is 
required on the next CEB 


Bit 0: 0 = No RQD required on next 
CEB sent 
1 = RQO required on next CEB 
sent 


® <A count of normal-flow requests 


Bits 0-14: A count of the number of 
normal-flow requests sent and 
received since the last-sent 
(RQD,CEB) 


When ai normal-flow response (except for 
RSP(RTR)) or a SIGNAL is sent, OFC places the 
contents of the CURRENT_BRACKET_SQN register 
in the sequence number field (SNF) of the 
response or SIGNAL. The current bracket 
sequence is not used for RSP(RTR) because it 
does not flow within a bracket. 


RQD REQUIRED ON CEB: RQD is required on some 
CEB requests to enable proper recognition of 
stray SIGNALs and stray responses. Since the 
CURRENT_BRACKET_SQN field is 15 bits, an 
identical value can occur after 2**15 RUs 
flow, causing the field to wrap. This can 
lead to confusion when recognizing stray 
SIGNALS and stray responses. In order to 
avoid this confusion, the normal flow is 
cleaned out periodically by the use of an 
(RQD,CEB) request and its response. This 
results in the following: 


1. Whenever the count of normal-flow 
requests reaches 2*#14¢, the indication 
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that a definite response is required on 
the next CEB 1s set to YES. 


2. Whenever the indication that a definite 
response is required on the next CEB is 
set to YES, the next CEB request is sent 
using RQD1, RQD2, or RQD3. The indi- 
cation that a e§ definite response is 
required on the next CEB is reset to NO 
and the count of normal-flow requests is 
reset to 0. If DFC receives the CEB with 
an indication to send it RQE1l (e.g., the 
transaction program issued DEALLOCATE 
with the FLUSH option), DFC will change 
it to RQD1 in order to comply with this 
rule. When a response is received to an 
(RQD1,CEB) request, no information is 
forwarded to PS because the transaction 
program 1s no longer communicating with 
the half-session. 


RECEIVING SIGNAL REQUESTS: When SIGNAL is 
received, the DFC component of the 
half-session does the following: 


1. Validates the SIGNAL code--if it is other 
than Request to Send (X'00010001'), an 
UNBIND indicating protocol error 
(X'FE,10050000') is sent. The SIGNAL 
response 1S sent immediately. This cre- 
ates the potential for receiving further 
SIGNALS before this one 1s processed. A 
l-deep queue for SIGNAL is defined, so 
later SIGNALs overlay earlier ones. If 
overlaying occurs, the receiving trans- 
action program only gets a single indi- 
cation that a SIGNAL has been received, 
even though more than one SIGNAL has been 
sent. This 3s sufficient since all 
SIGNALS indicate Request to Send. 


2. Places the SIGNAL in the correct brack- 
et--the TH identifier field (SNF) is com- 
pared against the CURRENT_BRACKET_SQN 
register. 


°® If they are equal, the SIGNAL is 
accepted and processed. 


e If the SIGNAL is early (see Fig- 
ure 6.1-5 on page 6.1-6 and Fig- 
ure 6.1-6 on page 6.1-6), it 1s 
pushed into the correct bracket by 
saving the SIGNAL value until the 
correct BB arrives, which can be 
several brackets in the future. 


© If the SIGNAL is late (see Fig- 
ure 6.1-4 on page 6.1-6), it 1s dis- 
carded because the transaction 
program is no longer communicattiinyg 
with the half-session (1.7., the con- 
versation has ended,. 


3. "sports receipt of the SIGNAL, via a 
REQUEST_TO_SEND record, to the PS cyompo- 
nent of the transaction's process. See 
"Chapter Bals Presentation Serv- 
ices--Conversation Verbs" for further 
discussion of the PS logic. 


RECEIVING RESPONSES: When a response 15 
received, the DFC component: 


1. Identifies failures--path errors = and 
invalid sense code values are detected 
and a conversation failure is reported to 
PS and RM. An UNBIND(X'FE....') with 
sense code from the negative response is 
sent to terminate the session itself. 


2. Detects stray negative responses--the TH 
identifier field (SNF) of the response is 
compared against the CURRENT _BRACKET_SQN 
register. If they are equal, the -RSP is 
intended for the current chain. If the 
-RSP is late (see Figure 6.1-4 on page 
6.1-6), it is discarded because the 
transaction program the response. is 
intended for is no longer communicating 
with the half-session. (If a positive 
response, other than +RSP(SIG), 1s not in 
the correct bracket, an UNBIND protocol 
error (X'FE,200E0000') 1s sent; +RSP(SIG) 
is discarded. ) 


3. Reports RTR responses--responses to RTR 
are reported to RM without regard for the 
bracket boundaries. 


4. Reports responses to RQD1 requests--in 
general, responses to RQD1 requests, such 
as a Bid request (LUSTAT with (RQD1,BB)); 
are reported to RM; an exception is 
RSP(SIG), which is reported to PS. 


5. Reports responses to RQD2 and RQD3 
requests--responses to RQD2 and RQD3 
requests are reported to PS. 


SEND ERROR Processing 


PS issues the SEND_ERROR command to DFC when 
PS is in HDX receive state, in order to 
change to send state so that it (PS) can send 
FMH-7(Error Description). (If already in 
send state, PS sends the FMH-7 without issu- 
ing the SEND_ERROR command; see "Chapter 5.0. 
Overview of Presentation Services" for more 
details.) 


Issuing SEND_ERROR in receive state causes 
DFC to send -RSP(ERP message forthcom- 
ing--0846) if some data has been received. 
If no data has been received, DFC waits until 
a chain is received and then responds with 
-RSP(0846). 


After the EC request is received, PS can send 
the FMH-7(Error Description); the  FMH-7 
includes sense data for PS's use—it is not 


processed bv OFC. If the EC request ended 
the bracket, PS does not send the FMH-7. 


DETAILED DESCRIPTION OF DFC FUNCTIONS 


REQUEST/RESPONSE FORMATTING 


DFC optionally checks that the requests and 
responses it receives are formatted correct- 
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ly. The formatting checks involve: 


® Enforcing that invalid RH bit combina- 


tions are not used, e.g.» BBI=BB and 
BCI=-BC, or CDI=CD and ECI=~EC. 


® Enforcing that the FM profile 19 rules 
are not violated, e.g., the receiving of 
an expedited-flomw DFC request other than 
SIGNAL, or the receiving of a request 
with BB that is neither LUSTAT nor FMH-5 
(Attach). 


Format checks occur before the use of 
finite-state machines (FSMs). (State checks 
are checks that involve FSMs.) FSMs require 
the BIU record to be formatted correctly 
before processing it. 


CHAINING PROTOCOL 


Chaining provides a means to send (and 
receive) a sequence of requests as one entity 
in the context of error recovery. At most 
one response is sent per chain. 


A chain consists of a single response RU or 
one or more request RUs with the following 
properties: 


e The requests belong to the same flow (ex- 
pedited or normal). 


© The requests flow in the sawe direction. 


© The first request is marked BC (Begin 
Chain) in the RH. 


e The last request is marked EC (End Chain) 
in the RH. 


® All requests that are neither first nor 
last are marked (-BC, ~EC) in the RH. 


The checking of received requests for proper 
chaining is provided for each half-session. 


Each response and each expedited-flow request 
is a single-RU chain, i.e., the RH indicates 
(BC,EC). 

Only chains of the following types are sent: 


chain: Each 
chain is marked 


® Exception-response (RQE) 
request in = the 
exception-response. 


® Definite-response (RQ0) chain: The last 
request in the chain is wmarked 
definite-response; all other requests in 
the chain are marked exception-response. 


See “Appendix 0D. RH Formats" for details of 
the possible variations within each type. 


The sender of the chain sets the Forw of 
Response Requested bits properly in = each 
request of the chain. Thus, the receiver of 
a chain need examine the Form of Response 
Requested bits only in the last request in a 
chain, or in a request in error. 


' Normal-flow DFC requests are not sent while 


sending a normal-flow FMO multiple-request 
chain. 


If ae chain sender receives a negative 
response to a chain being sent, the chain may 


be ended prematurely by sending the 
end-of-chain (EC) request. 


REQUEST/RESPONSE CORRELATION 


In order to remember the information on 


normal-flow jochains that OFC sends or 
receives, DFC maintains two correlation 
entries: one for sent chains and one for 


received chains. There can never be wore 
than one sent or received chain outstanding 
at any point in time (FM profile 19 protocol 
rules do not allow it), hence the need for 
enly two entries. <A correlation entry is 
established when the first RU in a chain is 
sent or received. The entry is reset when 
the chain has been completely processed, that 
is», when the end-of-chain request and its 
response, if any, have been processed. A 
correlation entry includes such information 
as selected RH parameters needed by OFC 
(a.g., RU category, 8BI, and CEBI), and the 
DFC request code. 


Some examples of how the correlation entry is 
used are: 


e When receiving a response, the entry for 
the sent chain is checked to verify that 
the RU category in the response is the 
same as the RU category of the sent 
chain. 


® When sending a response, the entry for 
the received chain is examined to deter- 
mine whether a bracket has begun (ji.e., 
the first RU in the chain was FMO with 
BBI=BB, or the single-RU chain was LUSTAT 
with BBI=BB). 


REQUEST/RESPONSE MODE PROTOCOLS 


Every half-session issues requests and 
responses according to the immediate request 
mode and the immediate response mode. Imme- 
diate request mode means that all request 
chains are sent under the constraint that no 
request may be sent by a given half-session 
when a previously sent request is still 
awaiting a response or reply. (A reply is a 
request sent in reaction to a received RQE 
request unit.) Request chains are replied or 
responded to in order of receipt. DFC 
enforces immediate request and response mode 
in the chaining FSMs. 


There are only two expedited RUs used (SIG 


and CRV) and both use the immediate request 
mode. The two RUs flow at different times 
(when in use, the CRV exchange is complete 
before SIG is ever sent), and therefore the 
protocol can be enforced by the initiating 
components--DFC enforces the protocol for 
$16, and TC enforces it for CRV. 


SNA Format and Protocol Reference Manual for LU Type 6.2 


The immediate response mode requires that 
responses be sent in the order the requests 
are received (ji.e., requests are processed 
and responses issued first-in, first-out). 
When a response to a particular request is 
received, it means that all requests in the 
same flow sent before the responded-to 
request have been processed by the receiver, 
and that their responses, if any, have been 
sent. 


BRACKET PROTOCOLS 


A bracket is a sequence of normal-flow 
request chains and their responses, exchanged 
in either or both directions between two 
half-sessions. Bracket protocols allow con- 
tention for session resources and assist in 
resolving the race condition that can result 
from that contention. 


The primary use of brackets is to carry con- 
versations between transaction programs. A 
transaction program requests a conversation 
with another transaction program by issuing 
the ALLOCATE verb. ALLOCATE causes’ the 
resources manager (RM) to select a 
half-session (based on ALLOCATE parameters) 
and attempt to initiate a bracket on it. If 
the bracket is successful, that half-session 
is used to carry the conversation. (See 
“Chapter 3. LU Resources Manager" for more 
details.) <A transaction program ends a con- 
versation by issuing a DEALLOCATE verb. This 
causes the half-session to terminate the 
bracket carrying the conversation. When the 
bracket terminates, the half-session becomes 
available again for selection by RM. 


The bracket rules regulate the initiation and 
termination of a bracket. 


A bracket is 
Begin Bracket (BB) in the first request of 
the first chains and CEBI to Conditional End 
Bracket (CEB) in the last request of the last 
chain in the bracket. 


BIND parameters specify one of the 
half-sessions as first speaker and the other 
as bidder. The first speaker has the freedom 
to begin a bracket without requesting permis- 
sion from the other half-session to do so. 
Any request carrying BB sent by the first 
speaker will begin a bracket. The bidder 
must request and receive permission from the 
first speaker to begin a bracket. The brack- 
et protocols are verified by the bracket 
state manager in the receiving half-session. 


The bidder may attempt to initiate a bracket 
(1.e., Bid) by sending an FMD request chain 


with (RQD,BB,QR) or with (RQE,BB,CD,QR). 
(See "“Queued Response Protocol" on page 
6.1-10 for description of QR usage.) The 


first speaker grants the attempt via a reply 
to an (RQE,CD) (see "Send/Receive Mode Proto- 
cols" on page 6.1-10 for definition of reply) 
or a positive or negative response (other 
than 0813, 0814, or 088B) or refuses the 
attempt via negative response (0813, 0814, or 
088B). 


delimited by setting BBI to 


A negative response with sense code 0813, 
0814, or 088B indicates that the first speak-~- 
er has denied permission for the bidder to 
begin a bracket. A READY TO RECEIVE (RTR) 
request may be sent later by the first 
speaker when permission to start a bracket is 
granted. (The first speaker may or may not 
have the capability to subsequently send RTR. 
The 0814 sense code is used only when the 
first speaker has the capability to send 
RTR.) If the first speaker will send RTR 
later, the sense code with the negative 
response is 0814 (Bracket Bid Reject--RTR 
Forthcoming). In this case, the bidder waits 
for the RTR before sending another BB. If 
the RTR will not be sent, the sense code is 
either 0813 (Bracket Bid Reject--No RTR 
Forthcoming) or 088B (BB Not Accepted--BIS 
Reply Requested). In the 0813 case, the bid- 
der will send BB again, if it still wants to 
begin a bracket. In the 088B case, the BB is 
not sent again because no more conversations 
will be allowed to start. <A BIS request will 
be received shortly and a BIS reply will be 
sent. 


Expedited requests and responses are not 
affected by bracket indicators on normal-flow 
requests, nor by the states of the bracket 
FSMs. 

rules 


The following apply to the bracket 


indicators: 


¢ BB may be indicated only on the first (or 
only) request of a chain. 


e CEB may be indicated only on the last (or 
only) request of a chain. It indicates 
the last chain in the bracket. (If CEB 
is set, CD must not be indicated because 
CEB overrides CD.) 


¢ BB and CEB may both be indicated within 
the same chain. 


* BB or CEB may be 
half-session. 


indicated by either 


e BB or CEB indicated on FMD 


requests. 


may be 


® Neither BB nor CEB may be indicated on 
any normal-flow DFC request except 
LUSTAT. 


e Neither BB nor CEB may be indicated on 
responses or on expedited requests. 


The following bracket termination rule is 
used: 


Bracket Termination Rule: Bracket termi- 
nation is influenced by whether the RU 
carrying CEB is an RE, RQD1, or RQD2|3, 
request. If the request is RQD2|3 the 
bracket terminates only upon receipt of a 
positive response; a negative response to 
the chain causes the session to remain in 
bracket. If the RU is sent as RQE, the 
bracket terminates unconditionally upon 
the sending of that RU. <A negative 
response to an (RQE,CEB) request will not 
find an entry in the receive correlation 
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entity, and therefore is logged and dis- 
carded. If the RU is specified as RQD1, 
the bracket terminates unconditionally 
upon receipt of a response to the chain, 
whether the response is positive or nega- 
tive. RQD1 is generated by DFC for the 
sequence number wrap case (unless the 
request is already RQD2|3) and for the 
DEALLOCATE TYPE(ABEND_*) verb. When DFC 
uses RQD1, PS and the transaction program 
consider the conversation to be termi- 
nated when the DEALLOCATE TYPE(ABEND_*) 
or DEALLOCATE TYPE( FLUSH) verb is issued: 
PS and the TP don't expect a response. 
DFC waits for a response before inforwing 
RM that the session is available for a 
new conversation. 


No more than one BB can be outstanding from a 
half-session. 


The normal-flow DFC requests, RTR and BIS, 
may be sent only between brackets and do not 
carry bracket bits. FMD requests always car- 
ry BB when flowing between brackets. LUSTAT 
is treated exactly like an FMD request con- 
taining (BC,EC), and may be used with BB to 
bid for, or with CEB to end, a bracket. 


The following types of error conditions are 
detected in the management of brackets: 


® Bracket protocol errors detected at the 
receiver and caused by sender error. 


e Errors detected at the receiver = and 
caused by race conditions. The appropri- 
ate action is for the receiver to send a 
Bracket Bid Reject sense code (0813, 
0814, or 088B) on a negative response to 
the other half-session. <A retry of the 
operation may be necessary. 


SEND/RECEIVE MODE PROTOCOLS 


Once a bracket has started, 
send/receive mode protocol is half-duplex 
flip-flop (HDX-FF). One half-session is des-~ 
ignated HDX-FF bidder, and the other, HDOX-FF 
first Speaker. Parameters in BIND specify 
which half-session is first speaker and which 
is bidder. The bidder may send a request 
containing BB, but its bid for the bracket is 
pending until it receives a response. 


the normal-flos 


Once a bracket is begun, a half-duplex 
flip-flop state is established, and the send- 
er issues normal-flow requests and the 
receiver issues responses. When the sender 
completes its transmission of normal-flow 
requests, tt transfers control of sending to 
the other half-session by setting the Change 
Direction indicator to CD on the last request 
sent. See "Bracket Protocols" on page 6.1-9 
for additional details. 


The Change Direction indicator (CDI) is used 
in the HDX-FF protocols. Only a request on 


the normal flow that is marked End Chain may 
carry CDI=CD. When the sending half-session 
includes CD in a request, it indicates that 
it is prepared to receive and that its paired 
half-session may send. CO is not conveyed in 
a response or on a request that carries CEB. 


An exception-response (RQE) chain always has 
CD indicated on the last RU of the chain, 
unless that RU carries CEB, in which case it 
does not indicate CD. 


A "reply" is the request sent by a 
half-session immediately after receiving an 
(RQE,CD) chain. A reply is treated as 
implicitly containing a positive response. 
That is, once an (RQE,CD) chain is replied 
to, a negative response to that chain is not 
permitted. A BIS, RTR, or an RU carrying BB 
ig not treated as a reply. 


QUEUED RESPONSE PROTOCOL 


DFC enforces the setting of the Queued 
Response indicator (QRI) bit on requests. 
The setting of the QRI bit is the same for 
all RUs in a chain. See "Appendix D. RH For- 
mats" for a discussion of this RH indicator. 


QR is always indicated on a chain carrying BB 
that is sent by the bidder. When QR is indi- 
cated in a response, that response will not 
pass any other RUs flowing through the net- 
work on the same session. It is used so that 
a positive response to the bidder's BB chain 
will not interfere with a bracket sent earli- 
er by the first speaker. The positive 
response will be received after the first 
speaker's bracket ends. QR is not indicated 
on any other chain. 


PS SEND AND RECEIVE RECORDS 


This section describes hos the 
SEND_DATA_RECORD (sent from PS to HS) and the 
RECEIVE_DATA record (sent from HS to PS) are 
mapped to and from the RH portion of a BIU 
containing a request. The SENO_DATA_RECORD 
is used by PS to send data in accordance with 
the verbs issued by a transaction program. 
This record (defined using transaction pro- 
gram verb terminology) is mapped into a 


request BIU by DFC before being sent. The 
RECEIVE DATA record is used to inform PS 
about data recefved on the half-session. 


This record (defined using transaction pro- 
gram verb terminology) is mapped from a 


received BIU containing ® request. Fig- 
ure 6.1-7 on page 6.1-11 svmmarizes the 
SEND _DATA_RECORD to RH mapping and Fig- 


ure 6.1-8 on page 6.1-11 summarizes the RH to 
RECEIVE DATA record mapping. 


SNA Format and Protocol Reference Manual for LU Type 6.2 


Parameters in SEND_DATA_RECORD 


ALLOCATE=YES (see Note 1) 


FMH=YES (see Note 1) 
NOT_END_OF_DATA “EC ,RQEL 
FLUSH “EC ,RQEL 


CONF IRM 
PREPARE_TO_RECEIVE_CONFIRM_SHORT 


EC ,RQD3 
| EC,CD,RQO3 
EC,CD,RQE3 


PREPARE _TO_RECEIVE_CONFIRM_LONG 


PREPARE_TO_RECEIVE FLUSH 

DEALLOCATE_CONFIRM 

DEALLOCATE_FLUSH with 
DEALLOCATE_ABENOD_* FM header 
{see Note 3) 

DEALLOCATE_FLUSH without 
DEALLOCATE_ABEND_* FM header 
(see Note 3) 


EC,CD,RQE1 
EC ,CEB,RQD3 


EC,CEB, RQDI 


EC,CEB, RQEL 


5 


53 


qua 
e 


| Request RH indicators 


BB 
FMH 


This parameter is used in conjunction with the rest of the parameters (e@.g., if ALLOCATE is YES and 


FMH is YES, specified with DEALLOCATE_CONFIRM, the request RH indicators are BS,FMH,EC,CEB,RQ03). 


2. RH indicators not shown (e.g., QRI) are set independently from the SEND_DATA_RECORD parameters. 


3. To indicate a DEALLOCATE_ABEND_* action, FMH is set to YES and DATA (offset 2 through 4) is set to 


X‘'070864'. 


Figure 6.1-7. SEND_DATA_RECORD to Request RH Mapping 


| Request RH indicators , 


| Ec,rRane|3 | CONFIRM 


EC,CD,RQ*x2|3 
EC,CD,RQE] 


| ec, ces rape] 3 
EC,CEB,RQE] or RQDI 


es: 


PREPARE_TO_RECEIVE_FLUSH 


| PREPARE_TO_RECEIVE_CONFIRM 


| DEALLOCATE_CONFIRM | 
| DEALLOCATE_FLUSH 


1, This parameter is set in conjunction with the rest of the parameters (e.g.» if FMH,EC,CEB,RQD2|3 
are indicated in the RH, FMH is YES and DEALLOCATE_CONFIRM is indicated in the RECEIVE DATA 


record). 


2. Other RH indicators (e.g., QRI) have no effect on the RECEIVE _DATA record parameter settings. 


Figure 6.1-8. Request RH to RECEIVE_DATA Record Mapping 


OFC REQUEST AND RESPONSE FORMATS 


This section describes the DFC request and 
response formats; the RH formats are shown in 


this section; the RU formats are shoo in 
"Appendix E. Request/Response Unit (RU) For- 
mats". Figure 6.1-9 on page 6.1-12 and Fig- 
ure 6.1-10 on page 6.1-13 show the format of 
DFC requests and responses, respectively. 
The Expedited Flow indicator (EFI in the TH) 
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DFC Request ----- > 
Header Indicators 


TH EFI 


RH Byte 0 Bit 0 RRI 


shows which flow, expedited or normal, the 
DFC request or response flows on. 


| LUSTAT SIGNAL 
tora [oe 
RQ RQ 


Bits 1-2 RU category 


Bit 3 reserved 
Bit 4 FI 
Bit 5 SDI 
Bit 6 BCI 
Bit 7 ECI 


DRIT 
reserved 
DReI 

ERI 
reserved 
reserved 


NSU PWN O 


RH Byte 2 Bit 0 BBI 
Bit 1 EDT 
Bit 2 cDI 
Bit 3 reserved 
Bit 4 reserved 
Bit 5 reserved 
Bit 6 reserved 
Bit 7. CEBI 
Notes: 
1. %*XX means either XX or “XX. 
2. See "Appendix D. RH Formats" for complete RH description. 
3. If CEBI is set to CEB, CDI is set to ~CD. 
G. For LUSTAT: (DRII,DR2I) = (0,1) | (1,0) | (1,1). 
5. For LUSTAT: QRI is set to QR when BBI is set to BB. 
6. The SNF and DCF TH fields are also set by DFC. 
7. The TH formats are not described in this volume. 


Figure 6.1-9. DFC Request Formats 
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}* 


DFC Response----- > RTR LUSTAT SIGNAL 
Header Indicators 


RH Byte 0 Bit 0 RRI 
Bits 1-2 RU category 
Bit 3 reserved 
Bit 4 FI 
Bit 5 SDI 
Bit 6 BCI 
Bit 7 


RH Byte 1 Bit 0 DRII 
Bit 1 reserved 
Bit 2 DReI 
Bit 3 RTI 
Bit 4 reserved 
Bit 5 reserved 
Bit 6 QRI 
Bit 7 PI 


Notes: 
1. *XX means either XX or ~XX. 
2. See "Appendix D. RH Formats" for complete RH description. 


3. For LUSTAT: DRII, DR2I, and QRI are set the same as they were 
on the request. 


4. The SNF and DCF TH fields are also set by DFC. 
5. The TH formats are not described in this volume. 


Figure 6.1-10. DFC Response Formats 
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6.1~14 


DFC REQUEST AND RESPONSE DESCRIPTIONS 


The DFC requests 


for FM profile 19 are 
described below. 


BIS (BRACKET INITIATION STOPPED ) 
Flow: 


Principal FSM: 
None in DFC 


BIS is sent by a half-session to indicate 
that it will not attempt to begin any more 
brackets (i.e., send any more BB requests). 


LUSTAT (LOGICAL UNIT STATUS) 


Primary to secondary and secondary to primary (Hormal) 


The use of BIS and it's principle FSMs are 
described in more detail in "Chapter 3. LU 
Resources Manager". “i 


Flow: Primary to secondary and secondary to primary (Normal) 


Principal FSM: 
Uses same FSMs as norwal-flow data 


LUSTAT is used to accompany RH bits. The sta- 
tus value is set to X'0006'. Specifically, 
LUSTAT is used in place of a null RU; that 
is, when it is time to send an RU to DFC, and 
the RU is marked (BC,EC) and has RU length = 
0, an LUSTAT(0006) is sent instead. This 
results in the following RH encoding with 
LUSTAT( 0006): 


i. (RQD1,BB): 
without data. 


Sending half-session bids 


2. (RQE2,CD): Sending half-session trans- 
fers send = control to the = other 
half-session, specifies that a Confirm be 
taken, and that completion of the Confirm 
be indicated by receipt of the next 
request from the other half-session. 
Confirwe--means that the transaction pro- 


gram connected to the other half-session 
has received and processed the RU data 
successfully. 


3. (RQD2,CD): Same as 2, except that com- 
pletion of the Confirm will be indicated 
by receipt of +RSP. 


4. (RQE1,CD): Sending half-session transfer 
send control to the other half-session 
specifying no Confirm. 


5. (RQD2,CEB): 
will be 
received. 


Same as 3, plus the bracket 
terminated when ai +RSP is 


6. (RQE1,CEB): Same as 4, plus the bracket 
is terminated unconditionally. 
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RTR (READY TO RECEIVE) 


Flow: First speaker to bidder (Normal) 


Principal FSM: 
None in DFC 


RTR indicates to the bidder that it is now 
allowed to initiate a bracket. An RTR 
request is sent only by the first speaker 
(see "Bracket Protocols" on page 6.1-9). The 


SIG (SIGNAL) 


use of RTR and it's principal FSMs are 
described in more detail in "Chapter 3. LU 
Resources Manager". 


Flow: Primary to secondary and secondary to primary (Expedited) 


Principal FSM: 
None 


SIG is an expedited request that can be sent 
between half-sessions, regardless of the sta- 
tus of the normal flows. It is the only 
expedited DFC request defined for FM profile 
19. It carries a four-byte value, of which 
the first two bytes are the Signal code and 


the last two bytes are the Signal extension 
value. 


The only Signal code defined for use with FM 
profile 19 is X'00010001'. This signal code 
is used in conjunction with the PS command 
REQUEST_TO_SEND. See "Chapter 5.1. Presenta- 
tion Services--Conversation Verbs" for more 
details. 
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DFC FOR CP-LU HALF-SESSIONS 


6.1-16 


The overview, structure, and protocol bounda- 
ries for DFC for CP-LU half-sessions is shown 
in Figure 6.1-11 on page 6.1-17. 


The CP-LU session uses FM profile 0 or 6. 
Immediate request and immediate response 
modes are used for FM profile 0. Delayed 
request and delayed response modes are used 
for FM profile 6. Chain 
form-of-response-requested indications for FM 
profile 0 are restricted to RQD, while FM 
profile 6 allows any (RQD, RQE, or RQN). FM 
profiles 0 and 6 share the following proper- 
ties: 


Only single-RU chains are allowed. 
Compression 1s not used. 

Brackets are not used. 

FM headers are not used. 

Alternate code is not allowed. 
Send/Receive mode is full duplex (FDX). 


DFC is initialized at half-session activation 
time to the FM profile being used. 


OVERVIEW OF DFC FUNCTIONS 


The functions of DFC for CP-LU half-sessions 
are: 


® Enforce correct request and response for- 
mats (e.g., RH parameter settings). 


® Enforce immediate request and immediate | 


response mode for sending and receiving 
normal-flow data. No enforcement is nec- 
essary for the delayed request or delayed 
response mode. 


Request/Response Formatting 


DFC optionally checks that received requests 
and responses are formatted correctly. For 
example, all RHs must have BCI=BC and ECI=EC. 
Formats may vary depending upon the FM pro- 
file used on the session. For instance, FM 
profile 0 allows chains asking only for defi- 
nite response (RQD). 


Immediate Request and Immediate Response Mode 
Enforcement 


DFC optionally checks that received requests 
do not violate immediate request mode proto- 
cols for sessions using FM profile 0. Once a 
request asking for a definite response has 
been received, it must be responded to before 
another request is received. Immediate 
response mode is also enforced for those ses- 
sions using FM profile 0. <Any = response 
received must be to an outstanding RQD 
request. | 


ERROR PROCESSING 


If a format error or immediate request or 
immediate response mode violation occurs, a 
negative response is sent if possible; other- 
wise, the error is logged. The half-session 
then continues, to run until it its destroyed 
(e.g.» via DACTLU). 
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LU Network Services (LNS) 


A 
INIT_HS HS_SEND_RECORD HS RCV_RECORD 
DFC_INITIALIZE DFC_SEND_FROM_LNS DFC_RCV 
(see note) (see note) 
A 
DFC 
BIU BIU 


Transmission Control (TC) 


Note: Called by half-session router ("Chapter 6.0. Half-Session") 


Figure 6.1-ll. Overview, Structure, and Protocol Boundaries of DFC for CP-LU Half-Sessions 
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HIGH-LEVEL PROCEDURES 


6.1-18 


DFC_INITIALIZE 


FUNCTION: 


_ INPUT: 


OUTPUT : 


NOTES: 


Initialize fields in the half-session's local storage (for ¢rocess data) that 
are used by DFC. This procedure is called by the half-session router ('"Chap- 
ter 6.0. Half-Session") when the half-session is created. 


INIT_HS record containing either ACTLU or BIND image; the following informa- 
tion is made available to DFC by the half-session router: FM profile type, 
indication that half-session is primary or secondary, LU_LID that identifies 
the LNS and RM associated with this half-session, HS_ID used to indicate to 
PS, RM, and LNS the half-session associated with a particular request. 


SUCCESSFUL return code and half-session initialized 


When a half-session is activated, it comes up in-brackets. The first BIU sent 
on the session uses a value of X'0001' in the TH sequence number field and 
does not carry BB. The BB, in effect, was carried on the session activation 
request (BIND). Therefore, the current bracket sequence number (LO- 
CAL.CURRENT_BRACKET_SQN) associated with the first bracket ona_e session is 
initialized to 0. 


The TS and FM profile type are checked for validity prior to calling this pro- 
cedure. 


Referenced procedures, FSMs, and data structures: 


FSM_BSM_FMP19 | page 6.1-43 
FSM_RCV_PURGE_FMP19 page 6.1-50 
FSM_QRI_CHAIN_RCV_FMP19 page 6.1-49 
FSM_CHAIN_RCV_FMP19 page 6.1-44 
FSM_CHAIN_SEND_FMP19 page 6.1-46 
FSM_IMMEDIATE_RQ_MODE_SEND page 6.1-48 
FSM_IMNEDIATE_RQ_MODE_RCV page 6.1-48 
LOCAL page 6.0-6 
INIT_HS page A-16 


Set all of the FSMs in this chapter to the reset state (state number 1). 
If the INIT_HS record is for an LU-LU session (contains a BIND image) then 
Record information from BIND image in the INIT_HS record that will be used by DFC 
throughout the life of this session: 
® First speaker or bidder (contention winner or loser) 
@ Maximum send RU size 
®e Alternate code set allowed 


Set LOCAL.SQN_SEND_CNT to 0. 

Set LOCAL.PHS_BB_REGISTER.BRACKET_STARTED_BY to PRI. 

Set LOCAL.PHS_BB_REGISTER.NUMBER to 0. 

Set LOCAL.SHS_BB_REGISTER.BRACKET_STARTED_BY to SEC. 

Set LOCAL.SHS_BB_REGISTER.NUMBER to 0. 

Set LOCAL.CURRENT_BRACKET_SQN.BRACKET_STARTED_BY to PRI. 
Set LOCAL.CURRENT_BRACKET_SQN.NUMBER to 0. (See Note 1) 


Set LOCAL.SEND_ERROR_RSP_STATE to RESET. 
Set LOCAL.SIG_RECEIVED to NO. 
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DFC_SEND_FROM_PS 
DFC_SEND_FROM_PS 


FUNCTION: Process records received from presentation services (PS). This procedure is 
called by the half-session router ("Chapter 6.0. Half-Session"). 


INPUT: PS_TO_HS_RECORD and the form of response requested for the last chain received. 


OUTPUT: Indication may be set that a negative response is to be sent to the next chain 
received (LOCAL.SEND_ERROR_RSP_STATE); a SIGNAL may be sent to the partner 
half-session. 


Referenced procedures, FSMs, and data structures: 


PROCESS _SEND_PARM page 6.1-35 
SEND_RSP_BIU page 6.1-38 
DFC_SEND_FSMS page 6.1-25 
FSM TialN_RCV_FMP19 page 6.1-44 
PS_TO_HS_RECORD page A-24 
SEND_DATA_RECORD page A-24 
SEND_ERROR page A-24 
REQUEST_TO_SEND page A-24 
CONFIRMED page A-24 
LOCAL page 6.0-6 


Select based on PS_TO_HS_RECORD type: 
When SEND_DATA_RECORD 
Call PROCESS_SEND_PARM(SEND_PARM from input record) (page 6.1-35). 


When CONFIRMED 
If last request received was RQD2 or RQD3Z then 
Call SEND_RSP_BIU (page 6.1-38) to send normal-flow, 
positive response. BIU_PTR passed to procedure has null value. 


When SEND_ERROR 
If state of FSM_CHAIN_RCV_FMP19 = BETC (between chains) then 
Set LOCAL.SEND_ERROR_RSP_STATE to NEG_OWED to indicate that a negative 
response should be sent to the next RU received. 
Else (send -RSP to chain currently being processed) 
Call SEND_RSP_BIU (page 6.1-38) to send normal-flow, -RSP with 
sense data X'08460000'. BIU_PTR passed to the procedure has null value. 


When REQUEST_TO_SEND 
Create a BIU and initialize it to all O's. See Appendix D. 
Set EFI to indicate expedited. 
Set RH as described in Figure 6.1-9 on page 6.1-12. 
Set RU as described under SIG request in Appendix E. 
Call DFC_SEND_FSMS(BIU) (page 6.1-25). 
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DFC_SEND_FROM_RM 


DFC_SEND_FROM_RM 


FUNCTION: Process records received from the resources manager (RM). This procedure is 
called by the half-session router ("Chapter 6.0. Half-Session'). 


INPUT : RM_TO_HS_RECORD, indication that session just started, first speaker indica- 
tor, primary or secondary half-session indicator, and 
LOCAL.SQN_SEND_CNT.NUMBER 


In addition an HS_PS_CONNECTED record may be received from RM 


OUTPUT: The following RUs may be sent: Bid with Attach (an Attach carrying BB), Bid 
LUSTAT (A LUSTAT carrying BB) BIS, RTR, or a YIELD SESSION LUSTAT (LUSTAT car- 
rying CEB). 


The following fields may be altered: LOCAL.CURRENT_BRACKET_SQN.NUMBER, 
LOCAL .CURRENT_BRACKET_SQN.BRACKET_STARTED_BY> LOCAL.PHS_BB_REGISTER.NUMBER; 
LOCAL.SHS_BB_REGISTER.NUMBER, 


In addition, the ID of the PS that is connected to this HS is saved to identi- 
fy the PS that is using this HS; indication that session just started. 


This procedure uses the BIU (see Appendix D ). In addition, the EFI field of 
the TH may be set. 


Referenced procedures, FSMs, and data structures: 


PROCESS_SEND_PARM page 6.1-35 
DFC_SEND_FSMS page 6.1-25 
FSM_BSM_FMP?!9 . page 6.1-43 
RM _TO_HS_RECORD page A-28 
BID_WITHOUT_ATTACH , page A~-29 
BID_WITH_ATTACH page A-28 
HS_PS_CONNECTED page A-29 
ENCIPHERED_RD2 | page A-30 
6.0-6 


LOCAL : page 


Select based on RM_TO_HS_RECORD type: 
When BID_WITH_ATTACH 
If the session just started (this is the first conversation on this session) then 
(no need to set current bracket sequence number because it has already 
been properly initialized) 
Receive the HS_PS_CONNECTED record that RM sends immediately after it sends the 
BID_WITH_ATTACH record. Save the PS identifier (HS_PS_CONNECTED.PS_ID). 
Call FSM_BSM_FMP19 (page 6.1-43) with an INB signal to indicate that 
this half-session is connected to a PS. 
Record that the session did not just start. 


Else (the session did not just start) 
If this half-session is the first speaker then 
Receive the HS_PS_CONNECTED record that RM sends immediately following the 
BID_WITH_ATTACH record. Save the PS identifier (HS_PS CONNECTED.PS_ID). 
Call FSM_BSM_FMP19 with an INB signal to indicate that this half-session is 
connected to a PS (page 6.1-43). 


The following sets the current bracket sequence number and LOCAL.*_BB_REGISTER 
before the BB request is sent: 
Set LOCAL.CURRENT_BRACKET_SQN.NUMBER to LOCAL.SQN_SEND_CNT.NUMBER + 1 (taking 
the wrap case into account). 
If the half-session is primary then 
Set LOCAL.CURRENT_BRACKET_SQN.BRACKET_STARTED_BY to PRI. 
Set LOCAL.PHS_BB_REGISTER.NUMBER to LOCAL.CURRENT_BRACKET_SQN.NUMBER. 
Else 
Set LOCAL.CURRENT_BRACKET_SQN.BRACKET_STARTED_BY to SEC. 
Set LOCAL.SHS_BB_REGISTER.NUMBER to LOCAL.CURRENT_BRACKET_SQN.NUMBER. 


Call PROCESS_SEND_PARM(BID_WITH_ATTACH.SEND_PARM) (page 6.1-35). 
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DFC_SEND_FROM_RM 


When BID_WITHOUT_ATTACH 

Create and send a (LUSTAT, BB, RQOL) recuest to bid for a conversation on 
this session as follows: 

Create a BIU and initialize it to all O's. Set EFI to indicate normal-flow. 
Set the RH to indicate DFC, FMH, BC, EC, RQD1, QR, and BB. Set the RU to an 
LUSTAT as described in Appendix E. 

Call DFC_SEND_FSMS(BIU) (page 6.1-25). 


When BIS_REPLY 
Create a BIU and initialize it to all 0's. Set EFI to indicate normal-flon. 
Set the RH to indicate DFC, FMH, BC, EC, RQE3, QR, and BB. Set the RU to 
BIS as described in Appendix E. 
Call DFC_SEND_FSMS(BIU) (page 6.1-25). 


When BIS_RQ 
Same as processing for BIS_REPLY (above) except RH indicates RQEL instead of RQE3. 


When HS_PS_CONNECTED 
Save the ID of the PS (HS_PS_CONNECTED.PS_ID) that 1s connected to this HS. 
Call FSM_BSM_FMP19 (page 6.1-43) mith an INB signal to indicata that 
this half-session is connected to a PS. 
If the session did not just start (i.e., this is not the first conversation 
on this session) then 
The following calculates the value for the current bracket sequence number and 
the BB_REGISTER before the BB request (to be sent) is received by DFC. 
Set LOCAL.CURRENT_BRACKET_SQN.NUMBER to LOCAL.SQN_SEND_CNT.NUMBER + 1 (taking 
the wrap case into account). 
If the half-session is primary then 
Set LOCAL.CURRENT_BRACKET_SQN.BRACKET_STARTED_BY to PRI. 
Set LOCAL.PHS_BB_REGISTER.NUMBER to LOCAL.CURRENT_BRACKET_SQN.NUMBER. 
Else 
Set LOCAL .CURRENT_BRACKET_SQN.BRACKET_STARTED_BY to SEC. 
Set LOCAL.SHS_ BB _REGISTER.NUMBER to LOCAL.CURRENT_BRACKET_S@QN.NUMBER. 
Else (session just started) 
Record that the session did not just start. 


When RTR_RQ 
Create a BIU and initialize it to all O's. Set EFI to indicate normal-flow. 
Set the RH to indicate DFC, FMH, BC, EC, and RQD1. Set the RU to RTR as 
described in Appendix E. 
Call DFC_SEND_FSMS(BIU) (page 6.1-25). 


When YIELD_SESSION 
If the session just started then 
Record that the session did not just start. 

The following sends an (LUSTAT, RQE1, CEB) to end the current conversation on 
this session. 

Create a BIU and initialize it to all O's. Set EFI to indicate normal-flow. 

Set the RH to indicate DFC, FMH, BC, EC, RQE1, and CEB. Set the RU to LUSTAT as 
described in Appendix E. 

Call DFC_SEND_FSMS(BIU) (page 6.1-25). 


When ENCIPHERED_RD2 
Call PROCESS_SEND_PARM( ENCIPHERED_RD2.SEND_PARM) (page 6.1-35). 
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DFC_SEND_FROM_LNS 
DFC_SEND_FROM_LNS 


Process record received from LU network services (LLNS). This procedure is 
called by the half-session router ("Chapter 6.0. Half-Session") and is used 
for SSCP-LU half-sessions only. 


HS_SEND_RECORD variant of LNS_TO_HS_RECORD 


TC.SEND procedure is called to send the data that is included in the input 
record to the partner half-session. 


Referenced procedures, FSMs, and data structures: 


TC.SEND page 6.2-13 
FSM_IMMEDIATE_RQ_MODE_SEND | page 6.1-46 
FSM_IMMEDIATE_RQ_MODE_RCV page 6.1~48 
LOCAL page 6.0~6 
LNS_TO_HS_RECORD page A-16 
HS_SEND_RECORD page A-16 


If FM profile = 0 (FM profile 0 uses immediate request mode.) then 
Call FSM_IMMEDIATE_R@_MODE_SEND( the BIU from the HS_SEND_RECORD.PIU) (page 6.1-48). 
Call FSM_IMMEDIATE_RQ MODE_RCV( the BIU from the HS_SEND_RECORD.PIU) (page 6.1-48). 


Call TC.SEND( the BIU from the HS_SEND_RECORD.PIU along with the EFI and SNF) (page 6.2-13). 


TRY_TO_RCV_SIGNAL 


Determine if a REQUEST_TO_SEND record should be sent to PS to indicate a SIG- 
NAL has been received. This procedure is called by the half-session router 
(“Chapter 6.0. Half-Session"). 


Indication that a SIGNAL has been received (LOCAL.SIG_RECEIVED), the sequence 
number of the signal, LOCAL .CURRENT_BRACKET_SQN, LOCAL.PHS_BB_REGISTER, 
LOCAL .SHS_BB_REGISTER 


REQUEST_TO_SEND sent to PS if required, indication that a SIGNAL has been 
received (LOCAL.SIG_RECEIVED) altered if stray SIGNAL detected. 


Referenced procedures, FSMs, and data structures: 


FSM_BSM_FMP19 | page 6.1-43 
REQUEST_TO_SEND page A-13 


If the state of FSM_BSM_FMP19 is INB and LOCAL.SIG_RECEIVED = YES then 
If the sequence number of the received SIGNAL request = LOCAL.CURRENT_BRACKET_SQN then 
(a SIGNAL request has been received for the current bracket). 
Create and send a REQUEST_TO_SEND record to PS. 
Set LOCAL.SIG_RECEIVED to NO. 
Else (the SIGNAL is either stray or future) 
Set BB_REGISTER (see below) to the low-order 15 bits of either LOCAL.PHS_BB_REGISTER or 
LOCAL .SHS_BB_REGISTER according to the value of the high order bit of the SIGNAL 
sequence number (e.g.,» if it indicates primary (1) use PHS_BB_REGISTER). 
Set SIG_ NUMBER (see below) to the low-order 15 bits of the SIGNAL sequence number. 


Calculate (SIG_NUMBER - BB_REGISTER) modulo 2%*15. 
If the result is 0 or > 2%#14 then | 
The SIGNAL is a stray that was intended for a previous conversation. 
Optionally log the condition and set LOCAL.SIG_RECEIVED to NO. 
Else 
The SIGNAL is for a future conversation. Save it until the bracket in 
which it was sent sent becomes the current bracket. 
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DFC_RCV 


DFC_RCV 


Process BIUs received from TC. This procedure is called by TC ("Chapter 6.2. 
Transmission Control"). 


BIU, FM profile type, LU_ID, and HS_ID 


LOCAL.SIG_RECEIVED is set if SIGNAL is received and the SNF of the SIGNAL is 
saved. 


This procedure and the procedures it calls use the BIU see Appendix 0 and 
Appendix E In addition, the EFI and SNF fields of the TH are used. 


Referenced procedures, FSMs, and data structures: 


DFC_RCV_FSMS page 6.1-24 
FORMAT_ERROR page 6.1-26 
SEND_RSP_BIU page 6.1-38 
STRAY_RSP page 6.1-41 
SEND_NEG_RSP_OR_LOG page 6.1-37 
FORMAT_ERROR_SSCP_LU page 6.1-30 
STATE_ERROR_SSCP_LU page 6.1-40 
FSM_IMMEDIATE_RQ_MODE_SEND page 6.1-48 
FSM_IMMEDIATE_RQ_HODE_RCV page 6.1-48 
LOCAL page 6.0-6 

HS_RCV_RECORD page A-11 


If FM profile for this session is 19 (X'13'), indicating LU-LU session, then 
If the BIU indicates RQ, FMD, -SD, CODE1, and the RU length > 0 then 
Translate the data in the RU from ASCII to EBCDIC. 


Call FORMAT_ERROR(BIU) to perform optional format error checks (page 6.1-26). 
If a format error was found in the BIU then 
Return to the HS router ("Chapter 6.0. Half-Session'’) mith LOCAL.SENSE_CODE set 
to a nonzero value. This will cause the session to be deactivated and the 
half-session to be destroyed. 


Else (no format error) 
If RQ then 
If EFI = normal-flow then 
Call DFC_RCV_FSMS(BIU) (page 6.1-24). 
Else (expedited-flow SIGNAL request) 

Save only the latest SIGNAL request received. Set LOCAL.SIG_RECEIVED = YES and 
save the sequence number. The sequence nusber is used in determining the 
bracket the SIGNAL was intended for. 

Call SEND_RSP_BIU (page 6.1-38) to send an expedited positive 
response to the SIGNAL request immediately. 

Else (RSP) 
Call STRAY_RSP(BIU) to determine if response is stray (page 6.1-41). 
If response is not stray then 
Call DFC_RCV_FSMS(BIU) (page 6.1-24). 


Else (CP-LU half-session, FM profile 0 or 6.) 
Call FORMAT_ERROR_SSCP_LU{BIU) (page 6.1-30). 
Call STATE_ERROR_SSCP_LU(BIU) (page 6.1-40). 
If there is either a format or state error then 
Call SEND_NEG_RSP_OR_LOG(BIU) (page 6.1-37). 
Else (no errors) 
If FM profile = 0 then (FM profile 0 uses immediate request mode. ) 
Call FSM_IMMEDIATE_RQ MODE_SEND(BIU) (page 6.1-48). 
Call FSM_IMMEDIATE_RQ_MODE_RCV(BIU) (page 6.1-48). 


Incorporate the BIU in an HS_RCV_RECORD and send it to the LNS associated with this HS. 
The HS_RCV_RECORD includes the HS_ID to identify this half-session. 
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DFC_RCV_FSMS 


FUNCTION: 


INPUT : LOCAL.SEND_ERROR_RSP_STATE 


BIU containing echiest« or response, 


LOCAL.PHS_BB_REGISTER or LOCAL.SHS_BB_REGISTER; 
RSP_TO_REQUEST_TO_SEND record may be sent to PS 


OUTPUT: 


Enforce data flow control protocol= for “received requests and responses. 


LOCAL.SEND_ERROR_RSP_STATE3 


Referenced procedures, FSMs, and data structures: 

RCV_STATE_ERROR page 6.1-36 
GENERATE_ RM_ PS __ INPUTS page 6.1-31 
SEND_RSP_TO_RM_OR_PS page 6.1-39 
UPDATE_FSMS page 6.1-42 
SEND_RSP_BIU page 6.1-38 
FSM_RCV_PURGE_FMP19 page 6.1-50 
FSM_CHAIN_RCV_FMP19 page 6.1-44 
FSM_CHAIN_SEND_FMP19 page 6.1-46 
RSP_TO_REQUEST_TO_SEND page A-13 

LOCAL page 6.0-6 


Call RCV_STATE_ERROR(BIU) (page 6.1-36). These checks are optional. 
If a state error is found then 
An error has occurred that will cause this session to be deactivated and the 
half-session process to be destroyed. LOCAL.SENSE_CODE contains sense data 
indicating the type of error. The HS router ("Chapter 6.0. Half-Session") will 
cause the Benomnes termination of the half-session as a result of LOCAL.SENSE_ CODE 
being set. 


Else (no state error) 
Select based on RRI and EFI: 
When normal-flow request 
If BBI = BB then 
Set LOCAL.PHS_BB_REGISTER.NUMBER (if this half-session is primary) or 
LOCAL.SHS_BB_REGISTER. NUMBER Cif BEeenvony! to the low-order 15 bits 
of request SNF. 


If the state of FSM_RCV_PURGE_FMP19 ~# PURGE then 
Call GENERATE_RM_PS_INPUTS(BIU) (page 6.1-31). 
Else 
Call UPDATE_FSMS(BIU) (page 6.1-42). 


If LOCAL.SEND_ERROR_RSP_STATE = NEG_OWED, BCI = BC, BBI = ~BB, and 
(RU category is FMD or this request is an LUSTAT) then 
Call SEND_RSP_BIU(BIU, NORMAL, NEG, X'08460000') (page 6.1-38) to send 
negative response to the chain. 
Set LOCAL.SEND_ERROR_RSP_STATE to RESET. 


If the state of FSM_CHAIN_RCV_FMPL9 = PEND_RSP (a response is owed), CEBI = CEB, 
and form of response requested is RQD1 then 
Call SEND_RSP_BIU(BIU, NORMAL, POS, X'00000000') (page 6.1-38) to send 
a posttive response. 


When normal-flow response 
Call SEND_RSP_TO_RM_OR_PS(BIU) (page 6.1-39). 
Call FSM_CHAIN_SEND_FMP19(BIU) (page 6.1-46). 


When expedited-flow response (1.e., a positive response to SIGNAL) 
Create and send a RSP_TO_REQUEST_TO_SEND record to PS. 
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DFC_SEND_FSMS 


FUNCTION: Maintain states while sending requests and responses. 
INPUT: BIU containing request or response 


OUTPUT: TC.SEND is called with the BIU to send. In addition, the following fields may 


be set: sequence number for request or response, LOCAL.SQN_SEND_CNT, 
LOCAL.PHS_BB_REGISTER, LOCAL_SHS_BB_REGISTER, and RH fields. 


This procedure and the procedures it calls use the BIU see Appendix D and 
Appendix E. In addition, the EFI and SNF fields of the TH are used. 


Referenced procedures, FSMs, and data structures: 


TC.SEND page 6.2-13 
FSM_CHAIN_RCV_FMP19 page 6.1-44 
FSM_CHAIN_SEND_FMP19 page 6.1-46 
LOCAL page 6.0-6 


Select based on BIU.RRI and BIU.EFI: 
When normal-flow request 
Increment LOCAL.SQN_SEND_CNT.SQN by 1 (taking the wrap case into account) 
and assign it to the SNF for this request. 


If CEBI = CEB then 
Indicate RQD1 on this CEB request if necessary. A count is kept of all the 
normal-flow requests sent and received. When this count exceeds 16384 (2%#14) 
the next CEB request sent indicates RQD1 so that any SIGNAL requests or responses 


are flushed (received by this half-session) before the response to the RQD1 request. 


This allows stray SIGNALS and responses to be accurately recognized. 


If the state of FSM_CHAIN_RCV_FMP19 = PEND_SEND_REPLY then 
Call FSM_CHAIN_RCV_FMPI19(BIU) (page 6.1-44)3; this request is an implicit response. 


If BBI = BB then 
Set LOCAL.PHS_BB_REGISTER.NUMBER (if this half-session is primary) or 
LOCAL.SHS_BB_REGISTER.NUMBER (if secondary) to the low-order 15 bits 
of request SNF. 


If BCI = BC then 
Call FSM_CHAIN_SEND_FMP19(BIU, BEGIN_CHAIN) (page 6.1-46). 


If ECI = EC then 
Call FSM_CHAIN_SEND_FMP19(BIU, END_CHAIN). 


If it is specified to send the data as ASCII (implementation-defined) then 
Translate the data in the RU from EBCDIC to ASCII. Set CSI to CODE]. 


When normal-flow response 
If this is an RTR response then 
Set the SNF to the SNF value received on the RTR request. 
Else (response to FMD or LUSTAT) 
If this is a response to a BB chain then 
Set the high-order bit of the response SNF to indicate the half-session 
that sent the BB chain (if primary sent the BB, then the bit is 13 
otherwise, it's 0). Set the low-order 15 bits of the response SNF to 
the low-order 15 bits of the BB request. 
Else 
Set the SNF to LOCAL.CURRENT_BRACKET_SQN. 
Call FSM_CHAIN_RCV_FMPL9O(BIU) (page 6.1-44). 


When expedited-flow request (i.e.,» a SIGNAL request) 
Set the SNF to LOCAL.CURRENT_BRACKET_SQN. 


When expedited-flow response (i.e., a SIGNAL response) 
Set the SNF to the SNF value received on the SIGNAL request. 


Call TC.SEND(BIU along with the EFI and SNF of the TH) (page 6.2-13). 
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FORMAT_ERROR 


— 
FUNCTION: Perform format checks on all requests and responses for LU-LU session. These 
checks are optional. None, some, or all of these checks may be done. 
INPUT: BIU 
OUTPUT: TRUE if format error; otherwise, FALSE. If TRUE, LOCAL.SENSE_CODE is set to 
appropriate sense data. 
Referenced procedures, FSMs, and data structures: 
FORMAT_ERROR_RQ_FMD page 6.1-29 
FORMAT_ERROR_RQ_DFC page 6.1-28 
FORMAT_ERROR_NORM_RSP page 6.1-27 
FORMAT_ERROR_EXP_RSP page 6.1-27 
LOCAL page 6.0-6 


Select based on one of the following conditions: 
When request with RU category of FMD 
Call FORMAT_ERROR_RQ_FMD(BIU) (page 6.1-29). 


When request with RU category of DFC 
Call FORMAT_ERROR_RQ DFC(BIU) (page 6.1-28). 


When normal-flow response 
Call FORMAT_ERROR_NORM_RSP(BIU) (page 6.1-27). 


When expedited-flow response 
Call FORMAT_ERROR_EXP_RSP(BIU) (page 6.1-27). 


(LOCAL.SENSE_CODE is set with the sense data indicating the type of 
if an error is found by any of the above called procedures. ) 
If LOCAL.SENSE_CODE # 0 then 
Return with a value of TRUE (format error found). 
Else 
Return with a value of FALSE (no format error found). 
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error 


FORMAT_ERROR_EXP_RSP 


FORMAT_ERROR_EXP_RSP 


FUNCTION: Perform format checks on expedited-flow responses. These checks are optional. 


INPUT: BIU containing expedited-flow response 


OUTPUT: If error, LOCAL.SENSE_CODE is set to appropriate sense data. 


Referenced procedures, FSMs, and data structures: 
LOCAL page 6.0-6 


Select, in order, based on fields in the BIU: 

When RU category is not DFC 

Set LOCAL.SENSE_CODE to X‘'40110000'. 
When FI = -FMH 

Set LOCAL.SENSE_ CODE to X'400F0000'. 
When (SDI = SD and RTI = POS) or (SN™ = -~SD and RTI = NEG) 

Set LOCAL.SENSE_CODE to ¥%°+u130000'. 
When BCI = -BC or ECI = -EC 

Set LovaL.SENSE_CODE to X'400B0000'. 
wnen QRI = QR 

Set LOCAL.SENSE_CODE to X'40150090°. 
When request code # SIGNAL 

Set LOCAL.SENSE_CODE to X'40120000'. 
When RTI = NEG (-RSP to expedited request) 

Set LOCAL.SENSE CODE to BIU.SENSE CODE. 


FORMAT_ERROR_NORM_RSP 


FUNCTION: Perform format checks on normal-flow responses. These checks are optional. 


INPUT: BIU containing normal-flow response 


OUTPUT: If error, LOCAL.SENSE_CODE 1s set to appropriate sense data. 


Referenced procedures, FSMs, and data structures: 
LOCAL page 6.0-6 


Select,in order, based on BIU fields: 

When BCI = -BC or ECI = -EC 
Set LOCAL.SENSE_ CODE to X'400B0000'. 

When (SDI = SD and RTI = POS) or (SDI = ~SD and RTI = NEG) 
Set LOCAL.SENSE_CODE to X'40130000'. 

When RU category 1s DFC and FI = -FMH 
Set LOCAL.SENSE_CODE to X'40QF0000'. 

When RU category is FMD, RTI = POS, and FI = FMH 
Set LOCAL.SENSE_CODE to X'SO0OFO000'. 

When RTI = NEG (negative response) and the sense data is not X'08130000', 

X'08140000', X'08190000', X'08460000', or X'088B0000' 
Set LOCAL.SENSE_CODE to the response sense data. 
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FORMAT_ERROR_RQ_DFC 
FORMAT_ERROR_RQ_DFC 


Perform format checks for data flow control (DFC) requests. These checks are 
optional. 


BIU containing OFC request. 


If error, LOCAL.SENSE_CODE is set to appropriate sense data. 


Referenced procedures, FSMs, and data structures: 
FORMAT_ERROR_RQ_FMD page 6.1-29 
LOCAL page 6.0-6 


Select, in order, based on one of the following conditions: 
When normal-flow and the request code is not BIS; LUSTAT, or RTR 
Set LOCAL.SENSE_CODE to X'10030000'. 
When expedi ted- flow and request code is not SIGNAL 
Set LOCAL.SENSE_CODE to X'10030000'. 
When expedited-flomw and request code is SIGNAL but the SIGNAL Extension field is not 
set to "soft" 
Set  LICAL.SENSE_CODE to X'10050000'. 
When FI # FMH 
Set LOCAL.SENSE_CODE to X'400F0000'. 
When BCI = -BC or ECI = ~EC 
Set LOCAL.SENSE CODE to X'400B0000'. 
When CSI = CODE] 
Set LOCAL.SENSE_CODE to X'40100000'. 
When EDI = ED 
Set LOCAL.SENSE_CODE to X'40160000'. 
When PDI = PD 
Set LOCAL.SENSE_CODE to X'40170000'. 
Otherwise 
If request code is LUSTAT then 
If LUSTAT Status Value field is "no-op" (only valid LUSTAT type) then 
Call FORMAT_ERROR_RQ_FMD(BIU), since LUSTAT is like FM data (page 6.1!1-29). 
(LOCAL.SENSE_CODE set by called procedure if error.) 
Else 
Set LOCAL.SENSE_CODE to X' 10050000°. 


Else (not LUSTAT DFC request) 
Select, in order, based on one of the following: 
When (request code is BIS and form of response requested is not RQE] or RQE3) or 
(request code is not BIS and forw of response requested is not R&QD1) 

Set LOCAL.SENSE_CODE to X*40140000". 

When QRI = QR 
Set LOCAL.SENSE_CODE to X'40150000'. 

When BBI = BB or EBI = EB or CEBI = CEB 
Set LOCAL.SENSE_CODE to X'400C0000'. 

When CDI = CD : 
Set LOCAL.SENSE_CODE to X'40090000'. 
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FORMAT_ERROR_R@Q_FMD 


FUNCTION: Perform format checks on FM data (FMD) requests. These checks are optional. 


INPUT: BIU containing FMD request, indication that alternate code will or will not be 
used 


OUTPUT: If error, LOCAL.SENSE_CODE is set to appropriate sense data. 


Referenced procedures, FSMs, and data structures: 
LOCAL page 6.0-6 


Select, in order, based on one of the following conditions: 
When expedi ted-flow 
Set LOCAL.SENSE_CODE to X‘'40110000'. 
When the form of response requested is not RQE or RQD 
Set LOCAL.SENSE CODE to X'40140000'. 


When the form of response requested is RQD and ECI = -EC 
Set LOCAL.SENSE_CODE to X'40070000'. 

When BBI = BB and BCI = -=BC 
Set LOCAL.SENSE_CODE to X'40030000'. 


When BBI = BB and RU category is FMD and ~(FI = FMH and FM header type = 5) 
Set LOCAL.SENSE_CODE to X'40030000'. 

When CSI = CODE1 and alternate code will not be used 
Set LOCAL.SENSE_CODE to X'40100000'. 


When EBI = EB (EB not used with FM profile 19.) 
Set LOCAL.SENSE_CODE to X'40040000'. 

When CDI = CD and ECI = -EC (CD allowed only on EC) 
Set LOCAL.SENSE_CODE to X'40090000'. 


When CDI = CD and form of response requested is RQD1 (CD may not be sent RQD1) 
Set LOCAL.SENSE_CODE to X'40090000'. 

When CEBI = CEB and ECI = -EC. 
Set LOCAL.SENSE_CODE to X'40040000'. 


When (BB, ~QR) request is received from the bidder or 
(BB, QR) request is received from the first speaker 
Set LOCAL.SENSE_CODE to X'40180000'. 
When CEBI = CEB and CDI = CD (Transaction pregram verbs canrot aenerate tnis combination. ) 
Set LOCAL.SENSE_CODE to X'40090000'. 


When CEBI = CEB and ferm of response requested is RQE2 or RQE3 
(DEALLACATE-CONFIRM (CEB,RQD213) and DEALLOCATE-FLUSH (CEB,RQE1) are valid) 
Set LOCAL.SENSE_CODE to X'40040000°. 
When CEBI = -CEB, CDI = -~CD, ECI = -C, and form of response requested is RQE 
Set LOCAL.SENSE_CODE to X‘'40190000'. | 


When RU category 1s FMD, CEBI = ~CEB, and form of response requested is RQDI 
Set LOCAL.SENSE_CCDE to X'40190000'. 
When BBI = BB, CEBI = CEB, form of response requested is RQE1, and this 
half-session is the first speaker (BB, CEB, RQE not allowed from bidder) 
Set LOCAL.SENSE_CODE to X'40040000'. 


When FI = FMH, RU category is FMD, and FM header type is not 5 or 7 
If FM header type is 12 then 
If EC & ~CEB then 
Set LOCAL.SENSE_CODE to X'O80F6051'. 
Else (not FMH 5, 7 or 12) 
Set LOCAL.SENSE_CODE to X'10084001'. 
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FORMAT_ERROR_SSCP_LU 


FUNCTION: Perform format error checks on RUs received on the SSCP-LU secondary 
half-session (for FM profiles 0 and 6). These checks are optional; none; 
some, or all of the checks may be done. 


INPUT: BIU, indication of FM profile type 


OUTPUT: TRUE if error; otherwise, FALSE. If TRUE, LOCAL.SENSE_CODE is set to appro- 
priate sense data. 


Referenced procedures, FSMs, and data structures: 
LOCAL | page 6.0-6 


If expedited-flow then 
Set LOCAL.SENSE_CODE to X'40110000'. 
Else (normal-flow) 
If request (RRI = RQ) then 
Select, in order, based on one of the following conditions: 
When the RU length is < 3 
Set LOCAL.SENSE_CODE to X‘'10020000'. 
When RU category is not FMD 
Set LOCAL.SENSE_CODE to X'40110000'. 
When FI # FMH 
Set LOCAL.SENSE_CODE to X'400F0000'. 
When SDI = SD | 
Set LOCAL.SENSE_CODE to the first 4 bytes of the RU data. 
When BCI = -BC or ECI = -EC 
Set LOCAL.SENSE_CODE to X'400B0000'. 
When FM profile is 0 and the form of response requested is not RQD 
Set LOCAL.SENSE_ CODE to X'40140000'. 
When FM profile is 6 and the form of response requested 1s not RQE, RQD, or RQN 
Set LOCAL. SENSE_CODE to X'40140000'. 
When QRI = QR 
Set LOCAL. SENSE_CODE to X'40150000°. 
When PI = PAC 
Set LOCAL.SENSE_CODE to X'40080000'. 
When BBI = BB, EBI = EB, or CEBI = CEB 
Set LOCAL.SENSE_CODE to X'400C0000'. 
When CDI = CD 
Set LOCAL.SENSE_CODE to X'400D0000'. 
When CSI = CODE] 
Set LOCAL.SENSE_CODE to X'40100000°. 
When EDI = ED 
Set LOCAL.SENSE_CODE to xX' 40160000'. 
When PDI = PD 
Set LOCAL.SENSE_CODE to X'40170000'°. 
Else (response ) 
Select, in order, based on one of the following. ondi tions: 
When (RTI = POS and RU length < 3) or (RTI = NEG and RU length < 7) 
Set LOCAL.SENSE_CODE to X'10020000'. 
When RU category 1s not FMD 
Set LOCAL.SENSE_CODE to X'40110000'. 
When FI # FMH 
Set LOCAL.SENSE_ CODE to X'400F0000°. 
When BCI = -BC or ECI = ~EC 
Set LOCAL.SENSE_CODE to X'¢€030000"°. 
When (RTI = POS and SDF = $D) or (RTI = NEG and SDI = -SD) 
Set LOCAL.SENSE_CODE to X'40130000'. 
Whew QRI = QR 
Set LOCAL.SENSE_CODE to X'40150000'. 
When PI = PAC | 
Set LOCAL.SENSE_CODE to X'40080000'. 


If LOCAL.SENSE_CODE = 0 then 

Return with a value of FALSE (no format error found). 
Else 

Return with a value of TRUE (format error found). 
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FUNCTION: 


INPUT: 


OUTPUT : 


Referenced procedures, FSMs, and data structures: 


tent. 


GENERATE_RM_PS_ INPUTS 


Generate the appropriate records for RM and PS based on the passed BIU's con- 


BIU containing normal-flow request, information about the last request sent 


In addition, a BID_RSP or an RTR_RSP record may be received from RM. 


Appropriate records sent to RM and PS. 
PS connected to this HS 


LOCAL.CURRENT_BRACKET_SQN, 


ID of the 


PROCESS _RU_DATA page 6.1-34 
OK_TO_REPLY page 6.1-33 
SEND_RSP_BIU page 6.1-38 
UPDATE_FSMS page 6.1-42 
FSM_BSM_FMP19 page 6.1-43 
FSM_RCV_PURGE_FMP19 page 6.1-50 
HS_TO_RM_RECORD page A-13 
ATTACH_HEADER page A-13 
BID page A-14 
BID_RSP page A-14 
FREE_SESSION page A-15 
BIS RQ page A-14 
BIS REPLY page A-14 
RTR_RQ page A-15 
RTR_RSP page A-15 
BID_RSP page A-28 
RTR_RSP page A-30 
LOCAL page 6.0-6 


Select, in order, based on one of the following conditions: 
When BB request 
Create and send a BID record to RM. 
Receive the BID_RSP from RM. 
If a positive Bid response is received (BID_RSP.RTI = POS) then 
Call UPDATE_FSMS(BIU) (page 6.1-42). 
If RU category is FMD then 
Call PROCESS RU_DATA(BIU) (page 6.1-34). 
Else 
Call SEND_RSP_BIU(BIU, NORMAL, POS, X'00000000') (page 6.1-38) to send 
a positive response to the BB request. 


Else (negative response to bid) 
Call FSM_RCV_PURGE_FMP19 SIGNAL( PURGE) (page 6.1-50) to cause the 
remainder of this BB chain to be purged. 
Call UPDATE_FSMS(BIU) (page 6.1-42). 
Call SEND_RSP_BIU(BIU, NORMAL, NEG, BID_RSP.SENSE_CODE) (page 6.1-38) to send 
a negative response to the BB request. 


When BIS request 
Call UPDATE_FSMS(BIU) (page 6.1-42). 
If the form of response requested = RQE1 then 
Create and send a BIS_RQ record to RM. 
Else (RQE3) 
Create and send a BIS_REPLY record to RM. 
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GENERATE_RM_PS_INPUTS 


When RTR request 
Create and send an RTR_RQ@ record to RM. 
Call UPDATE_FSMS(BIU) (page 6.1-42). 
Receive RTR_RSP from RM. 
If RTR_RSP.RTI = POS then 
Call SEND_RSP_BIU(BIU, NORMAL, POS, BID_RSP.SENSE_CODE) (page 6.1-38) to send 
a positive response to the RTR request. 
Else (negative response to RTR) 
Call SEND_RSP_BIU(BIU, NORMAL, NEG, RTR_RSP. SENSE_ CODE) (page 6.1-38) to send 
a negative response to the RTR request. 


Otherwise 
Call OK_TO_REPLY(BIU) (page 6.1-33) to determine if BIU is a reply. 
If BIU is a reply then 
If FSM_BSM_FMP19 is in BETB state, and the last sent chain carried BB 
(this BIU is a reply to BB) then 
Create and send a BID_RSP (positive) record to RM. 
Receive the HS_PS_ CONNECTED record from RM (this is a reply to the BID_RSP record). 
Record the ID of the PS connected to this HS. 
Set LOCAL.CURRENT_BRACKET_SQN to the sequence number of the sent BB request. 
Call FSM_BSM_FMP19 (page 6.1-43) with an INB signal to indicate 
that this HS is now connected to a PS. 


If the last chain sent was RQE2 or RQE3 then 
Create and send a CONFIRMED record to PS. 


Call PROCESS_RU_DATA(BIU) (page 6.1-34). 
Call UPDATE_FSMS(BIU) (page 6.1-42). 


INVALID_SENSE_CODE 


FUNCTION: Determine if sense data on negative response is valid. 


INPUT: BIU containing negative response, information about the last chain sent, 
speaker indicator 


OUTPUT: TRUE if invalid sense data; otherwise, FALSE 


If this is a response to a BB chain then 
If this half-session is first speaker then 
If the response sense data is not X'08460000' or X'088B0000' then 
Return with a value of TRUE Cinvalid sense data). 
Else (bidder) 
If response to LUSTAT then (1.e., RSP(LUSTAT,BB) ) 
If the response sense data is not X'08130000', X'08140000', 
or X'088B0000' then 
Return with a value of TRUE (invalid sense data). 
Else (response to BB not LUSTAT) 
If the response sense data is not X'08130000', X'08140000', 
X'088B0000', X'08460000' then 
Return with a value of TRUE (invalid sense data). 


Else (response to -BB chain) 
If response to RTR then 
If the response sense data is not X'08190000'° then 
Return with a value of TRUE (invalid sense data). 
Else (not response to RTR) 
If response to BIS then (negative response to BIS not allowed) 
Return with a value of TRUE Cinvalid sense data). 
Else 
If the sense data is not X'08460000' then 
Return with a value of TRUE (invalid sense data). 


Return with a value of FALSE (valid sense data). 
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OK_TO_REPLY 


OK_TO_REPLY 


FUNCTION: Determine whether or not a request is a valid reply. A reply is a request 
sent (or received) after receiving (or sending) an (RQE,CD) request. 


INPUT: BIU containing a normal-flow request, LOCAL.CURRENT_BRACKET_SEQUENCE_NUMBER, 
information about the last chain sent 


OUTPUT: TRUE 1f valid reply; otherwise, FALSE 


Referenced procedures, FSMs», and data structures: 


FSM_BSM_FMP19 page 6.1-43 
FSM_CHAIN_RCV_FMP19 page 6.1-44 
FSM_CHAIN_SEND_FMP19 page 6.1-46 
LOCAL page 6.0-6 


Select, in order, based on one of the following conditions: 
When the request is BIS or RTR 
Return with a value of FALSE (not a valid reply). 


When the request indicates BB or -BC 
Return with a value of FALSE (not a valid reply). 


When (sending and the state of FSM_CHAIN_RCV_FMP19 is not PEND_SEND_REPLY) or 
(receiving and the state of FSM_CHAIN_SEND_FMP19 is not PEND_RCV_REPLY) 
(page 6.1-44 and page 6.1-46) 

Return with a value of FALSE (not valid reply). 


When receiving and state of FSM_BSM_FMP19 (page 6.1-43) is INB and the 
last chain sent carried BB and LOCAL.CURRENT_BRACKET_SQN # the SNF of that chain 
Return with a value of FALSE (not a valid reply). 


Return with a value of TRUE (a valid reply). 
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PROCESS_RU_DATA 


FUNCTION: Process an RU and, based on the content of the RU, send the appropriate 


records to RM and PSs. | 


INPUT; BIU containing a normal-flow request, LOCAL.SHS_8B_REGISTER, 


LOCAL.PHS_BB_REGISTER, HS_ID, DCF from TH of request, indication that 


half-session is primary or secondary 


In addition, an HS_PS_CONNECTED record may be received from RM. 


OUTPUT: Appropriate records sent to RM and PS; if an FMH-5 is present, 
LOCAL .CURRENT_BRACKET_SQN is set and ID of PS that is connected to this HS is 
saved. 

NOTE : PS and RM require that any FMH data is sent in a separate record from other RU 
data. 


Referenced procedures, FSMs, and data structures: 


FSM_BSM_FMP19 : page 6.1-43 
RECEIVE_DATA page A-12 
HS_TO_RM_RECORD page A-13 
ATTACH_HEADER | page A-13 
HS_PS_CONNECTED | page A-29 
SECURITY_HEADER ! page A-15 
LOCAL page 6.0-6 


Determine if a complete FM header is present. FM headers may fit into a single RU 
(along with other data) or span several RUs within a chain. FM header data is treated 
se arately from other data. When FM headers span RUs (this can be determined by examining 
the data count field and the FMH length fields) the data is accumulated 

until the entire header has been received. The RH of the first (or only) RU containing 
an FM header indicates FMH and an RU category of FMD. FMH is indicated only in the first 
RU; successive RUs containing FM header data indicate 7-FMH. 


If a complete FM header is present then 
Select based on the FM header type: 
When type 5 (Attach) 

Create and send an ATTACH HEADER record (contains the FM header 5 data) to RM. 

Receive the HS_PS_ CONNECTED record from RM (this ts a reply to ATTACH_HEADER). 
Save the ID of the PS that is cornmected to this HS. 

Call FSM_BSM_FMP19 (page 6.1-43) with an INB signal to 
indicate that this HS is now connected to a PS. 


Update the current bracket sequence number using the sequence number of the 
last received BB request as follows: 
If this half-session is primary then 
Set LOCAL.CURRENT_BRACKET_SQN to LOCAL.SHS_BB_ REGISTER. 
Else 
Set LOCAL .CURRENT_BRACKET_SQN to LOCAL.PHS BB_REGISTER. 


When type 7 (Error data) 
Create a RECEIVE DATA record and send it to PS (FMH=YES, TYPE=NOT_END_OF DATA, 
DATA=FM header 7 data from BIU). 


When type 12 (Security header) 
Create and send a SECURITY_HEADER record (contains the FM header 12 data) to RM. 


If EC or data other than FM header data is present then 


Create and send a RECEIVE_DATA record to PS (FMH=NO, DATA=non-FMH data from BIU, 
TYPE = see Figure 6.1-8 on page 6.1-11). 
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PROCESS_SEND_PARM 


Create and send FMD requests. The appropriate RH indicators are set for each 
RU of a chain based on the input parameters. Each RU size will not exceed the 
maximum RU size specified at session activation. 


SEND_PARM record 


One or more BIU records sent representing each RU, LOCAL.SEND_BUFFER 


Referenced procedures, FSMs, and data structures: 


SEND _BIU page 6.1-37 
SEND_PARM page A-36 
LOCAL page 6.0-6 


If SEND_PARM.FMH = YES and LOCAL.SENO_BUFFER contains data then 
Call SEND_BIU(data in LOCAL.SENO_BUFFER, FLUSH) (page 6.1-37) to flush 
out data so this FM header may begin in a new RU. 


Concatenate data to be sent (SEND_PARM.DATA) with the data in LOCAL.SENO_ BUFFER. 


Divide LOCAL.SENO_BUFFER into pieces of the maximum size and send all but the 
last one by calling SENO_BIU and passing it the data from the send buffer and 
indicating that it needs to be flushed. The last piece is saved to 

minimize sending null RUs (RUs that contain no data). Otherwise, if the last 
piece is sent and the next SEND from PS indicates EC but no data, a null EC 
would have to be sent. 


If SEND_PARM.TYPE = NOT_END_OF_DATA or 
(SEND_PARM.TYPE = FLUSH and the LOCAL.SEND_BUFFER is empty) then 
Don't send out a BIU now. 


Else (send out a BIU) 
Call SEND_BIUC LOCAL .SEND_BUFFER, SEND_PARM.TYPE) (page 6.1-37). 
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RCV_STATE_ERROR 


Perform state error checking on received requests and responses. The types of 
errors found here are protocol violations by the sender of the request or 


response. These checks are optional. None, some, or all of the checks may be 
made. 


BIU containing request or response, indicator that a response to a SIGNAL is 
expected 


TRUE if a state error was encountered; otherwise, FALSE. If TRUE; 
LOCAL.SENSE_CODE is set to appropriate sense code. 


Referenced procedures, FSMs, and data structures: 


INVALID_SENSE_CODE ~ page 6.1-32 
FSM_BSM_FMP19 page 6.1-43 
FSM_QRI_CHAIN_RCV_FMP19 page 6.1-49 
FSM_CHAIN_RCV_FMP19 page 6.1-44 
FSM_CHAIN_SEND_FMP19 page 6.1-46 
LOCAL page 6.0-6 


Select based on EFI and RRI: 
When normal-flow request 
Select based on the following conditions: 
When a (RQE,BB,CEB) chain is received from the bidder 
Set LOCAL.SENSE_CODE to X'40040000' ((RQE,BB,CEB) not allowed from bidder). 


When executing FSM_BSM_FMP19(BIU) (page 6.1-43), 
FSM_CHAIN_RCV_FMP19(BIU) (page 6.1-44), or 
FSM_QRT_CHAIN_RCV_FMP19(BIU) (page 6.1-49) would cause a state 
check (>) condition | 
Execute the corresponding output code in the first FSM that encountered 
a state-check condition (to set LOCAL.SENSE_CODE). 


When normal-flow response 
Select based on the following conditions: | 
When RU category of the response # RU category of the request 
Set LOCAL.SENSE_CODE to X'40110000'. 
When RU category of the response = DFC and the request code of the response 
* the request code of the request 
Set LOCAL.SENSE_CODE to X'40120000'. 
When the QRI field of the response * the QRI of the request 
/ Set LOCAL.SENSE_CODE to X'40210000'. 
i When response is negative and contains an invalid sense data 
(call INVALID_SENSE_CODE(BIU) [page 6.1-32]) 
Set LOCAL.SENSE_CODE to X'20120000'. 
When executing FSM_CHAIN_SEND_FMPI19(BIU) (page 6.1~46). 
would cause a state-check (>) condition 
Execute the corresponding output code (to set LOCAL.SENSE_CODE). 


When expedited-flow response (i.e., a positive response to SIGNAL) 


If a SIGNAL request is not outstanding (not waiting for response to SIGNAL) then 
Set LOCAL.SENSE_CODE to X'200E0000' (response correlation error). 


6.1-36 SNA Format and Protocol Reference Manual for LU Type 6.2 


SEND_BIU 
SEND_BIU 


FUNCTION: Create and send a BIU according to passed instructions. 


INPUT : DATA, SEND_PARM.TYPE, information from SEND_DATA_RECORD 


Appropriate BIU sent 


Referenced procedures, FSMs, and data structures: 
DFC_SENO_FSMS page 6.1-25 


Create a BIU and initialize it to all 0's. 
If starting a new chain (the last RU sent was EC) then 
Set BCI to BC. 
Set other RH indicators as described in Figure 6.1-7 on page 6.1-11. 
If sending a BB chain and this half-session is the bidder then 
Set QRI to QR for every RU in this chain. 
Set the RU to the passed input data. 
If this BIU indicates (BC, EC) and there is no data in the RU then 
Convert the RU to an LUSTAT (RH indicates FMH and DFC; RU contains an LUSTAT 
(see Appendix E). 


Call DFC_SEND_FSMS(BIU) (page 6.1-25). 


SEND_NEG_RSP_OR_LOG 


FUNCTION: Convert the BIU to a negative response or log the error. 
INPUT: BIU and LOCAL.SENSE_CODE 


OUTPUT: Response BIU sent if possible; otherwise, error logged 


Referenced procedures, FSMs, and data structures: 
TC.SEND page 6.2-13 
LOCAL page 6.0-6 


If BIU is a response or a request with a fors of response requested of RQN then 
Unable to send a negative responses optionally log the error. 


Else (this is a request to which a negative response may be sent) 
Build and send a negative response. This is done by copying the RH, EFI, 
and SNF from the request to the response and setting the following RH 
fields: RSP, SD; BC, EC, NEG, ~PAC, -BB, ~CD, CODEO, -ED, -PO, ~CEB 


Set the response BIU RU to LOCAL.SENSE_CODE followed by the 

request code of the request BIU. For CP-LU sessions the BIU 

indicates FMH, the RU category is FMD, and the request code is 3 bytes long. 
For request with an RU category of DFC the request code is 1 byte long. 


Call TC.SEND( response BIU along with the SNF and EFI) (page 6.2-13). 
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SEND_RSP_BIU 


FUNCTION: Create and send a response. The response is based on the request BIU (if 
passed by the caller) or on information about the last received chain (when a 
null BIU is passed). | 


Request BIU (may be null value), flow (expedited or normal), response type 
(positive or negative), sense data (Information about the last received chain 
will be used when the input request BIU has a null value.) 


OUTPUT: BIU containing response sent if possible 


Referenced procedures, FSMs, and data structures: 
DFC_SEND_FSMS page 6.1-25 
FSM_CHAIN_RCV_FMP19 page 6.1-44 


Create a response BIU and initialize it to all O's. 
Set the RH fields of the response BIU to (RSP, BC, EC). 
If the input response type is negative (NEG) then 
Set the RH to (SD, NEG) and copy the input sense data into the response BIU data. 


If input flow is normal then 
If input request BIU has null value then 
Copy the RU category; FI; DRII; DR2I; QRI3; and if the RU category = DFC, the request 
code; from the last received normal-flow request into the response BIU. 
Else (a request BIU was passed as input) 
Copy the RU category; FI; DRII; DR2I; QRI3; and if the RU category = DFC, the request 
code; from the input request BIU to the response BIU. 


Else (expedited, the only expedited-flow response is for SIGNAL) 
Set EFI to expedited, RU category to DFC, DR1, and request code to SIGNAL 
in the response BIU. 


(Note: the DFC request code always immediately follows the sense data in the RU) 


If executing FSM_CHAIN_RCV_FMP19( response BIU) (page 6.1-44) 
would cause a state-check (>) condition then 
Execute the corresponding output code in the FSM. 
Else 
Call DFC_SEND_FSMS(response BIU) (page 6.1-25) to send the response. 
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SEND_RSP_TO_RM_OR_PS 
SEND_RSP_TO_RM_OR_PS 


FUNCTION: Build and send records to RM or PS based on the passed response BIU. 


INPUT: BIU containing a response, indicator that session is first speaker, informa- 
tion about the last sent request. 


In addition, an HS_PS CONNECTED record may be received from RM. 
OUTPUT: The appropriate "response" record is sent to RM or PS. 


LOCAL.CURRENT_BRACKET_SQN set to the sequence number of the last sent BB 
request. The ID of the PS connected to this HS may be saved. 


Referenced procedures, FSMs, and data structures: 


FSM_BSM_FMP19 page 6.1-43 
CONFIRMED page A-12 
RECEIVE ERROR page A-l2 
BID_RSP page A-14 
RTR_RSP page A-15 
HS_PS_CONNECTED page A-29 
LOCAL page 6.0-6 


If the response 1s RTR then 
Create and send an RTR_RSP record to RM. 
Else 
If the response is positive (RTI = POS) then 
If last chain sent was a BB chain and the state of FSM_BSM_FMP19 
(page 6.1-43) is BETB then 
Create and send a BID_RSP (positive) record to RM. 
Receive the HS_PS_CONNECTED record from RM (this is a reply to BID_RSP record). 
Save the ID of the PS connected to this HS. 
Set LOCAL.CURRENT_BRACKET_SQN to the sequence number of the sent BB request. 
Call FSM_BSM_FMP19 (page 6.1-43) with an INB signal to 
indicate that this HS is now connected to a PS. 


If the form of response requested of the last chain sent was RQD2 or RQD3 then 
Create and send a CONFIRMED record to PS. 


Else (response is negative) 
If the response sense data is X'08460000' then 

If this half-session is not the first speaker and the last chain sent 

carried BB (this is a response to a bidder's BB with data) then 
Create and send a BID_RSP (positive) record to RM. 
Receive the HS_PS_CONNECTED record from RM (this is a reply to BID_RSP record). 
Save the ID of the PS connected to this HS. 
Set LOCAL.CURRENT_BRACKET_SQN to the sequence number of the sent BB request. 
Call FSM_BSM_FMP19 (page 6.1-43) with an INB signal to 

indicate that this HS 1s now connected to a PS. 


Create and send a RECEIVE_ERROR record to PS. 
Else (bracket reject, i.e., X'08130000', X'08140000', or X'088B0000' ) 


Create and send a BID_RSP record (indicates negative response and 
contains the sense data from the response) to RM. 
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STATE_ERROR_SSCP_LU 


FUNCTION: Perform state error checks on RUs received on the CP-LU secondary half-session 
(FM profiles 0 and 6). These checks are optional; none, some, or all of the 


checks may be done. | 


INPUT: BIU, FM profile type,» sequence number of the last sent request 


OUTPUT: TRUE if error; otherwise, FALSE. If TRUE, LOCAL.SENSE_CODE is set to appro- 
priate sense data. | 


Referenced procedures, FSMs, and data structures: 


FSM_IMMEDIATE_RQ_ MODE_SEND page 6.1-48 
FSM_IMMEDIATE_RQ MODE_RCV page 6.1-48 
LOCAL page 6.0-6 


If this session is using FM profile 0 (using immediate request mode) then 
If RRI = RQ then 
If executing FSM_IMMEDIATE_R@Q_MODE_RCV(BIU) (page 6.1-48) 
would cause a state-check (>) condition then 
Execute the corresponding output code in that FSM to set LOCAL.SENSE_CODE. 


Else (response) 
If the state of FSM_IMMEDIATE_RQ_MODE_SEND (page 6.1-48) is PEND_RSP © 
(Half-session is awaiting a response to a sent RQD request.) then 
If the response SNF # the SNF of the last sent request then 
Set LOCAL.SENSE_CODE to X'200E0000' (response correlation error). 
Else (not waiting for a response) | 
Set LOCAL.SENSE_CODE to X'200E0000' (response correlation error). 


If LOCAL.SENSE_CODE = 0 then 

Return with a value of FALSE (no state error). 
Else 

Return with a value of TRUE (state error). 
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STRAY_RSP 


Determine if a response is stray. A stray response is one that was sent in a 
bracket (conversation) but received in a different (later) bracket. 


BIU containing a response, information about the last request = sent, 
LOCAL .CURRENT_BRACKET_SQN 


TRUE if stray response; otherwise, FALSE. Yf stray response represents a 
response correlation error, LOCAL.SENSE_CODE is set. 


An outstanding request is a request that has not been responded to nor replied 
to. . 


Referenced procedures, FSMs, and data structures: 
FSM_BSM_FMP19 page 6.1-43 
LOCAL page 6.0-6 


If the response is RTR, there is an outstanding request chain, and the response SNF ¥ the 
sequence number of the outstanding (awaiting a response) request then 
Set LOCAL.SENSE_CODE to X'200E0000' (response correlation error). 
Indicate that the response is stray. 


If the response is SIGNAL and its SNF * LOCAL.CURRENT_BRACKET_SQN then 
Indicate that the response is stray. 


If the response is LUSTAT or the RU category is FIMO then 
If there is an outstanding request chain then 
If the outstanding chain carried BB and the BB SNF does not match 
that in the response then 
Indicate that the response is stray. 


Else 


If the response SNF # LOCAL.CURRENT_BRACKET_SQN or the state of 


FSM_BSM_FMP19 is BETB then 
Indicate that the response is stray. 


Else (no outstanding request chain) 
Indicate that the response is stray. 


If the response is stray then 
If the response is positive (RTI = POS) and it is not a SIGNAL 
(no positive response other than SIGNAL can be stray) then 
Set LOCAL.SENSE_CODE to X'200E0000' (response correlation error). 


Else 


Optionally log the stray response. 


Return with a value of TRUE (stray response). 


Else 


Return with a value of FALSE (not stray response). 
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UPDATE_FSMS 


Update the appropriate FSMs for received requests. 


BIU containing request 


FSMs updated 


Referenced procedures, FSMs, and data structures: 


FSM_RCV_PURGE_FMP19 page 6.1-50 
FSM_QRI_CHAIN_RCV_FMP19 page 6.1-49 
FSM_CHAIN_RCV_FMP19 page 6.1-44 
FSM_CHAIN_SEND_FMP19 page 6.1-46 


Call FSM_RCV_PURGE_FMPL9O(BIU) (page 6.1-50). 
If the state of FSM_CHAIN_SEND_FMP19 = PEND_RCV_REPLY then 
Call FSM_CHAIN_SEND_FMP19(BIU) (page 6.1-46). 


‘If BCI = BC then 
Call FSM_CHAIN RCV_FMP19(BIU, BEGIN CHAIN) (page 6.1~44). 


If ECI = EC then 
Call FSM_CHAIN_RCV_FMP19(BIU, END_CHAIN) (page 6.1~-44). 


Call FSM_QRI_CHAIN_RCV_FMPLO(BIU) (page 6.1-49). 
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FINITE-STATE MACHINES 


These are the FSM input definitions used for e RTR: BIU is an RTR RU. 
all the FSMs in this chapter: 

e FMH5: BIU contains an FMHS. 
® Ror S: BIU that is being processed is 


being received or sent, respectively. | @ FMH12: BIU contains an FMH12. 

e RQ, RSP, BC, EC, CD, CEB, FMD, QR: Refer ° LUSTAT: BIU is a LUSTAT request or 
to the RH of the BIU. response. 

e BEGIN_CHAIN or END_CHAIN: Refer to values ® NOT_BID_REPLY: BIU = BC, ~BB and either 
of CHAIN_INDICATOR. CHAIN_INDICATOR does the last sent chain did not carry BB or a 
not have to be specified. In that case, call to OK_TO_REPLY (page 6.1-33) returns 
it is neither BEGIN CHAIN nor END_CHAIN. a value of FALSE. 

e RQD: BIU = RQD1, RQD2, or RQD3. ® CEB_UNCOND: BIU = CEB and response cate- 


gory = (RQDIIRQE1). 


© RQE: BIU RQE1, RQE2, or RQE3. 


NOTE: FSM_IMMEDIATE_RQ_MODE_SEND and 

e REPLY: A call to OK_TO_REPLY(BIU) (page FSM_IMMEDIATE_RQ_ MODE_RCV are used for CP-LU 

6.1-33) returns TRUE. sessions. All others are used for LU-LU ses- 
sions. 


e BIS: BIU is a BIS RU. 


73n_BSM_FMP19 


FUNCTION: Enforce the bracket protocol. State transitions are made via the signals INB 
(go in brackets) and BETB (go between brackets). The inputs R,RQ,... are 
used for error checking only. INB state means DFC (the half-session) is con- 
nected to a PS; BETB state means DFC is not connected to a PS. 


INPUT: BIU or a signal that the FSM should be set to the specified state 


OUTPUT: If an error is discovered, LOCAL.SENSE_CODE is set. 


NOTE : The state names mean the following: 
e BETB: between brackets 


e INB: in bracket 


Referenced procedures, FSMs, and data structures: 
LOCAL page 6.0-6 


STATE NAMES---->| BETB | 
INPUTS STATE NUMBERS-->} 01 ! 
SIGNALC INB) | 
SIGNAL( BETB) 


R, RQ, (FHDILUSTAT)» NOT_BID REPLY) “FMH5) “FMH12,~CEB_ UNCOND 


| OUTPUT 
; CODE 


PR | Set LOCAL.SENSE_CODE to X'20030000' (bracket error). 


FUNCTION 
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FSM_CHAIN_RCV_FMP19 


FUNCTION: Enforce the chaining protocol for received chains. A chain is "complete" when 
the end-of-chain (EC) request has been received and any required associated 
response or reply has been sent. A reply is a request sent after receiving an 
(RQE,CD) chain that has not been negatively responded to. <A _ reply implies a 
positive response to the (RQE,CD) chain. 


INPUT: BIU, CHAIN_INDICATOR (possible values are BEGIN_CHAIN; END_CHAIN and 
NOT_SPECIFIED), information about the last received request 

OUTPUT: If the bracket was ended by the request, the HS will be disconnected from PS; 
information recorded about the last received request may be erased; 
LOCAL.SENSE_CODE may be set. 
The state names mean the following: 
e BETC: between chains 


e INC: in the middle of a chain 


NEG RSP SENT: in the middle of a chain and a negative response has been 
sent 


PEND RSP: has received (EC,RQD) and is waiting for the response to be 
sent | 


PEND SEND REPLY: has received (EC,RQE,CD) and is waiting for the reply or 
negative response to be sent 


Referenced procedures, FSMs, and data structures: 


OK_TO_REPLY page 6.1-33 
FREE_SESSION page A-15 
LOCAL —_ a page 6.0-6 
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PEND 
RSP 
04 


STATE NAMES~----> 


INPUTS STATE NUMBERS--> 


R,RQ,BEGIN_CHAIN 
R,»RQ,END_CHAIN,RQD 
R,RQ,END_ CHAIN, RQE,CEB 
R,»RQ,END_CHAIN,RQE,CD 
R,»RQ,END_CHAIN,BIS 


S,-RSP,(FMDILUSTAT) 
S,+RSP,(FMD|LUSTAT) 
S,tRSP,RTR 


S,RQ,REPLY 
R,RQ,BC >(R2) 
R,RQ,-~BC >(R2) 


SIGNALCRESET ) 


If the last chain received did not carry BB or 
(it carried BB and it was accepted, i.e., there was no negative response to the 
BB chain with sense data X'08130000', X'08140000', or X'088B0000') then 
If the bracket has ended (the last received chain carried CEB and either [1] 
the form of response requested was RQE or RQD1, or [2] no negative response 


was sent to the chain) then 
Stop communication between PS and HS. This involves purging records currently 
in transit from PS and disabling PS's capability to send to this HS. 
Create and send a FREE_SESSION record to RM. 
Call FSM_BSM_FMP19 with a BETB signal (page 6.1-43). 


Set LOCAL.SENSE_CODE to X'200A0000' (immediate request mode error). 


Set LOCAL.SENSE_CODE to X'20040000' (half-duplex error) . , 
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6.1-46 


FUNCTION: 


INPUT: 


OUTPUT : 


_ FSM_CHAIN_SEND_FMP19 


Enforce the chaining protocol for sending chains. A chain is "complete" when 
the end-of-chain (EC) request has been sent and any required associated 
response or reply has been received. A reply is a request received after 
sending an (RQE,CD) chain that has not received a negative response. A reply 
implies a positive response to the (RQE,CD) chain. 


BIU, CHAIN INDICATOR (possible values are BEGIN_CHAIN; END_CHAIN and 
NOT_SPECIFIED), information about the last received request : 


If the bracket was ended by the request, the HS will be disconnected from PS; 
information recorded about the last received request may be. erased; 
LOCAL.SENSE_CODE may be set. 

The state names mean the following: 

®  BETC: between chains 


e INC: in the middle of a chain 


NEG RSP RCVD: in the middle of a chain and a negative response has been 
received 


PEND RSP: has sent (EC,RQD) and is waiting for the response to be 
received : 


PEND RCV REPLY: has sent (EC,RQE,CD) and is waiting for the reply or neg- 
ative response to be received 


Referenced procedures, FSMs, and data structures: 


OK_TO_REPLY | page 6.1-33 
FSM_BSM_FMP19 : page 6.1-43 
FREE_SESSION page A-15 
LOCAL page 6.0-6 
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FSM_CHAIN_SEND_FMP19 


STATE NAMES----> 


INPUTS STATE NUMBERS--> 


S,RQ,BEGIN CHAIN 
S,RQ,END_CHAIN,RQD 
S,RQ,END_CHAIN,RQE,CEB 
S,RQ,END_CHAIN,RQE,CD 
S,RQ,END_CHAIN,BIS 


R»-RSP,( FMD] LUSTAT) 
R,+RSP,(FMD|LUSTAT) 
R,tRSP,»RTR 


R,RQ,REPLY 


OUTPUT | FUNCTION 
CODE 


If the last chain sent did not carry BB or 
(it carried BB and it was accepted, 1.e., there was no negative response to the 
BB chain with sense data X‘'08130000', X'08140000', or X'088B0000') then 
If the bracket has ended (the last sent chain carried CEB and either [1] 
the form of response requested was RQE or RQD1, or [2] no negative response 


was received for the chain) then 
Stop communication between PS and HS. This involves purging records currently 
in transit from PS and disabling PS's capability to send to this HS. 
Create and send a FREE_SESSION record to RM. 
Call FSM_BSM_FMP19 with a BETB signal (page 6.1-43). 


Set LOCAL.SENSE_CODE to X'200F0000' (response protocol error). 
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FSM_IMMEDIATE_RQ_MODE_SEND 


FSM_IMMEDIATE_R@_MODE_SEND 


FUNCTION: Enforce the immediate request mode send protocol. It 1s used only 
half-sessions using FM profile 0. | 


INPUT: BIU 


OUTPUT : LOCAL.SENT_RQD_SNF may be set. 


NOTE: The state names mean the following: 
@ RESET: no request is awaiting a response. 


@  PEND_RSP: a response is expected to the last sent request. 


STATE NAMES----> 
INPUTS STATE NUMBERS--> 


| S,RQ,RQD 
R, RSP 


SIGNAL(RESET } 


FSM_IMMEDIATE_RQ MODE_RCV 


FUNCTION: Enforce the immediate request mode receive protocol. It is used only 
half-sessions using FM profile 0. 


INPUT: BIU 
OUTPUT: LOCAL.SENSE_CODE is set if an error is found. 
NOTE: The state names mean the following: 

® RESET: a response its not owed to a chain. 


© PEND RSP: a chain was received to which a response is owed. 


Referenced procedures, FSMs, and data structures: 
LOCAL page 6.0-6 


STATE NAMES----> 
INPUTS | STATE NUMBERS--> 


R,»RQ,RQD 
S»tRSP 


SIGNALCRESET ) 


OUTPUT | FUNCTION 
CODE 


a Set LOCAL.SENSE_CODE to X'200A0000' (immediate request mode violation). 
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FSM_QRI_CHAIN_RCV_FMP19 
FSM_GRI_CHAIN_RCV_FMP19 


Enforce the setting of the QRI indicator in the RH. This indicator is set the 
same for all BIUs in a chain; i.e., all BIUs in a chain have @RI=QR or have 
QRI=-QR. 

BIU 


If a QRI state error is detected, LOCAL.SENSE_CODE is set. 


1) The state names mean the following: 


@ RESET: no chain is currently being received. 
e INC QR: the chain that is being received is a QR chain. 
e INC NOT QR: the chain that is being received is not a QR chain. 


2) The implementation of this FSM is optional because it is used only to 
detect receive error conditions. 


Referenced procedures, FSMs, and data structures: 
LOCAL 


STATE NAMES----> 


STATE NUMBERS-->/| 
R,RQ, QR, EC 
k R,RQ, QR, “EC 


| R»RQ,-QR, EC 
R,RQ,~QR,~EC 


SIGNAL(RESET) 


OUTPUT | FUNCTION : 
| CODE : 


}e | Set LOCAL.SENSE_CODE to X'200B0000' (QRI state error). 
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FSM_RCV_PURGE_FMP19 


6.1-50 


FSM_RCV_PURGE_FMP19 


Maintain a purging state for received BB chains that have been negatively 
responded to indicating a bracket error (0813, 0814, 0888). It is called with 
a PURGE signal when the negative response is sent and reset when the 
end-of-chain (EC) RU is received. When in the purging state, no records are 


generated for PS or RM as a result of receiving a request RU in the BB chain 
(i.e., the remainder of the BB chain is purged). 


BIU 
None 


7 | STATE NAMES--~--> 
INPUTS . STATE NUMBERS--> 


R, EC : 
SIGNAL( PURGE ) 


SIGNAL( RESET) 
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CHAPTER 6.2. TRANSMISSION CONTROL 


INTRODUCTION 


A distinct transmission control (TC) element 
is provided for each half-session supported 
in a node. 


Each TC element participates in two activ- 
ities: 


e Initialization: 


The protocol machine for session initializa- 
tion, TC.INITIALIZE (page 6.2-8), is invoked 
after LU netvork services (LNS) processes a 
BIND or § ACTLU. TC.INITIALIZE, provides 
session-specific support for starting data 
flows in the session. When session-level 
cryptography is used, TC.INITIALIZE checks 
that the enciphering and deciphering func- 
tions are operative before any user data is 


- Variable initialization permitted to flow. 

- Cryptography initialization 

The TC.SEND and TC.RCV components control 
sequence number checking, pacing,» enciphering 
and deciphering, and manage expedited and 


normal flows. 


® Normal operation: 


- Sending data from data flow control 
(DFC) to path control (PC) 
- Receiving data from PC and givina it The relationship of transmission control to 
to DFC the other elements of the half-session, after 
initialization, is shown in Figure 6.2-1. 


Presentation Services (See Chapter 5.0.) 
A 


.- Data Flow Control ** 


e 


Hal f—Session 


Router * Transmission Control 


Half—Session 


sent data 
V 
Path Control 


received data 


* See "Chapter 6.0. Half-—Session" for details. 
*% See "Chapter 6.1. Data Flow Control" for details. 


Figure 6.2-1. Structure of TC and Flow of Data within the Half-Session 
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INITIALIZATION PHASE 


6.2-2 


TC.INITIALIZE (page 6.2-8) is called by 
half-session initialization ("Chapter 6.0. 
Half-Session") during initialization when a 
hal f-session is being activated. The 
initialization procedure sets up pacing, 
CRYPTOGRAPHY VERIFICATION (CRV), and sequence 
number usage variables according to the TS 
profile in use. 


CRYPTOGRAPHY VERIFICATION (CRV) 


For sessions that support cryptography, the 
initialization procedure calls 
TC .EXCHANGE_CRV (page 6.2-10) to perform the 
message-unit exchanges necessary to enable 
data enciphering and deciphering. 


Flow: From primary LU to secondary LU (Expedited) 


When session-level cryptography is specified 
in the BIND, CRV is sent by the primary LU TC 
to the secondary LU TC to enable sending and 
receiving of enciphered FMD requests by both 
half-sessions. CRV is a valid request only 
when session-level cryptography is selected 
in BIND. CRV carries an 8-byte field (see 
"Appendix E. Request/Response Unit (RU) For- 
mats") that contains a transform of the deci- 
phered test value (enciphered under the 
session cryptography key). The test value is 
received by the primary LU in the +RSP(BIND); 
the transform in CRV is the test value with 
each bit of its first four bytes inverted 
(i.e., a 1 becomes a 0 and a 0 becomes a 1). 
(The test value is also used as the session 
seed, or initial chaining value, when enci- 
phering and deciphering FMD RUs while the 
session is active.) The secondary TC element 
obtains the returned test value by decipher- 
ing the aforementioned 8-byte field in CRV 
and inverting the first four bytes; it then 
compares it with the test value sent (enci- 
phered) in +RSP(BIND). Failure to compare 
resets the session cryptography key and the 
session seed. Failure to compare also causes 
the session to be deactivated. 


Valid cryptography options are defined under 
the BIND format in "Appendix E. 
Request/Response Unit (RU) Formats"; "Appen- 
dix D. RH Formats" describes the RH bits used 
for cryptography. 


Where session cryptography is used, session 
key distribution is managed by the CP of the 
primary LU; session keys are conveyed (enci- 
phered under LU master cryptography keys) to 
the PLU in a CINIT RU and then to the second- 
ary LU in a BINO request (see "Appendix E. 
Request/Response Unit (RU) Formats" and Fig- 
ure 6.2-2 on page 6.2-3). The flows involved 
in distributing the session seed to the LU 
are shown in Figure 6.2-2 on page 6.2-3. 


The comments below correspond to the numbers 
in Figure 6.2-2 on page 6.2-3. 


1. In the CINIT RU, the session cryptography 
key is distributed to the primary LU in 


two enciphered formats: it is enciphered 
using the master cryptography key of the 
primary LU and in another field it is 
enciphered using the master cryptography 
key of the secondary LU. The initial 
chaining value is 0 for both cases. 


2. In the BIND RU, the primary LU sends the 
session cryptography key to the secondary 
LU as it was received in the CINIT RU: 
enciphered using the master cryptography 
key of the secondary LU as the 
cryptography key and 0 as the initial 
chaining value. 


3. The secondary LU deciphers the session 
cryptography Key using its waster 
cryptography Key as the cryptography key 
and 0 as the initial chaining value. The 
secondary LU then generates a 
pseudo-random value, retains it for use 
as the session seed, and enciphers it 
using the session cryptography key as the 
cryptography key and 0 as the initial 
chaining value. This enciphered value is 
returned on the response to BIND. The 
value serves two purposes: it is used as 
a test value (i.e., shen returned in CRV 
discussed below), and is subsequently 
used as the session seed, or initial 
chaining value, in enciphering and deci- 
phering FMD requests within the session. 


4. The primary LU deciphers the test value 
received in the RSP(BIND) using the ses- 
sion cryptography key as the deciphering 
key and 0 as the initial chaining value. 
The resulting value is retained for use 
as the session seed and then transformed 
by exclusive-ORing it with 
X'FFFFFFFFO00000000'. This inverts the 

bit settings in the first four bytes. 
The transformed value is then enciphered 
using the session cryptography Key as the 
key and 0 as the initial chaining value. 
This transformed, enciphered value is 
sent on the CRV request. 


5. The secondary LU deciphers the enci- 
phered, transformed test value using the 
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CP 


PRIMARY LU 


CINIT (MKp [SK] 0, MKs [SK] 0) 


SK 
SS 


> 
BIND (MKs [SK] 0) 


RSP(BIND, SK [SS] 0) 
< 


CRV(SK [transformed 5S] 0) 


RSP(CRV) 
< 


e 


o 


FMD request(SK [RU data] SS) 


SECONDARY LU 


C1) 
[2] 


> 


[3] 


[4] 
> 


[5] 


[6] 
> 


FMD request(SK [RU data] $5) [6] 
C eexnnencceemnonennene-ceneen cette anaes POO DSSS SSNPS 


waster cryptography key for primary LU (obtained from 
installation- and implementation-dependent system definition). 

master cryptography key for secondary LU fobtained from 
installation- and implementation-dependent system definition). 


session cryptography key 
session seed 


NOTE: Enciphered data is represented in the diagram as follows: 


cryptography Key [ data ] initial chaining value 


For example, to show an RU that was enciphered using the session key 
as the cryptography key and 0 as the initial chaining value, 
the following string is used: 


Figure 6.2-2. 


SK [RU data] 0. 


session cryptography key as the key and 0 
as the initial chaining value. The 
result is then = exclusive-ORed = with 
X'FFFFFFFF00000000' to recreate the ori- 
ginal pseudo-random value sent by the 
secondary LU in RSP(BIND). The recreated 
value is compared with the actual value 
that was created by the secondary LU. If 
the recreated value matches the original 
value, a positive response is sent to 
CRV. The test value can then be used as 
the session seed. 


From then on, all FMD requests are enci- 
phered using the session cryptography key 
as the Key and the session seed as the 
initial chaining value. 


Cryptography verification is the only session 


control 


(SC) request handled by TC. SC 


Distributing the Session Cryptography Key and Session Seed to the LU 


requests for session activation and deacti- 
vation (for example, BIND and UNBIND) are 
routed from PC to LNS (see "Chapter 4. LU 
Network Services") without passing through 
TC. Session control requests and responses 
have the header bit-settings described below. 


All SC requests are issued by TC or by LNS. 
The following fields of the TH and RH are set 
for session control RUs. 


TH: All SC requests and responses are 
sent expedited (the EFI bit is on in the 
TH). 


RH: The RH settings for SC requests are 
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‘DFC | 


—RSP 


TC.SEND < 
(page 6.2-13) 


@#eeoeoeeoeeoeeeeeee eee 0 @ 


TC.RCV 


DFC 


(page 6.2-15) 


oeeee8eee88e 0 © @ 


° 


TC. .DEQUEUE_ TC. TRY_TO_ 
PAC SEND_IPR 
(page 6.2-18) (page 6.2-19) 


RQ & RSP 


V V V 
Path Control (PC) e 


Figure 6.2-3. Interrelation of TC.SEND and TC.RCV 


NORMAL OPERATION 


The TC.SEND and TC.RCV protocol machines are 
related as shown in Figure 6.2-3. Detailed 
definitions for TC.SEND and TC.RCV, the major 
TC procedures, are shown on page 6.2-13 and 
page 6.2-15, respectively. 


The protocols supported by TC include: 


® Checking of sequence numbers on received 
normal-flow requests (Sequence numbers 
are assigned to normal-flow requests by 
DFC, see "Chapter 6.1. Data Flow Con- 
trol") 


e Proper separation of the normal flows 
from the expedited flows with respect to 
sequencing and pacing. 


® Sending of normal-flow requests using 
pacing; this involves a queue (LO- 
CAL.Q_PAC) for temporarily holding outgo- 
ing requests, and a set of coupled FSMs 
and procedures that manage the sending 
and receiving of pacing requests end 
responses (FSM_PAC_RQ_SEND [pane ¢€.2-20] 
and FSM_PAC_RQ_RCV IFr=ce 6.2-21)) 


RQ&RSP 


Half—Session Router (HS) 


® Proper routing of requests and responses 
to PC and DFC 


@ Enciphering and deciphering control for 
all LU-LU FMD request RUs on sessions 
using session-level mandatory 
cryptography (see TC.TRY_TO_ENCIPHER 
[page 6.2-14] and TC.RCV_NORM_RQ = [page 
6.2-17]) 


TC PROCEDURES INVOKED FROM OTHER COMPONENTS 
OF THE HALF-SESSION 


Procedures TC .RCV (page 6.2-15) and 
TC.TRY_TO_SEND_IPR (page 6.2-19) are invoked 
by the half-session router (see "Chapter 6.0. 
Half-Session" for details). 


When the half-session router receives a mes- 
sage unit from path control, it calls TC.RCV 
to initiats TC processing of the message 
unit. 


TC.TRY_TO_SEND_IPR, which is called period- 
ically from the half-session router, is 
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responsible for generating an ISOLATED PACING 
RESPONSE (IPR, see “Pacing'') when both the 
architectural and resource requirements are 
satisfied. 


TC.SEND (page 6.2-13) is called by DFC when 
DFC has a full buffer to send or when DFC is 
flushing a partially filled buffer. The 
buffer 1s considered full when it contains 
more than the maximum RU size as specified in 
BIND. 


SEQUENCE NUMBERING OF REQUESTS AND RESPONSES 


For TS profile 7 (used in LU-LU: sessions, see 
"Appendix F. Profiles") each request that is 
sent on the normal flow 1s assigned a 
sequence number. The sequence number is ini- 
tialized to 0 when a half-session is acti- 
vated (BIND is sent or received}; it is 
incremented by 1 before sending each request. 
Thus, the sequence number for the first 
request is 1. After reaching 65,535, the 
sequence number wraps to 0. (A sequence num- 
ber of 0 is sent in the wrap situation only. ) 
Sequence numbers are assigned in the sending 
half-session by DFC and are checked in the 
receiving half-session by TC. 


For the expedited flow, an identifier is 
assigned to each request sent. The identifi- 
er is not necessarily managed as a sequence 
number, but is used to uniquely identify each 
outstanding expedited-flow request sent. The 
expedited-flow DFC RU SIGNAL is assigned an 
identifier by DFC; the expedited-flow request 
CRV is assigned an identifier by TC; 
expedited-flow session-activation (BIND) and 
session-deactivation (UNBIND) requests are 
assigned identifiers by LNS (see "Chapter 4. 
LU Network Services"). 


For TS profile 1 (used in CP-LU and CP-PU 
sessions), identifiers are used on the normal 
flows as well as on the expedited flows. 


The sequence number or the identifier, as 
appropriate, 15 given to path control with 
the associated BIU, to be carried in the TH. 


The sequence number or identifier generated 
by the sending component is retained for use 
in correlating responses to requests (a 
response carries the sequence number or iden- 
tifier of the corresponding request). 


For further information on sequence number- 
ing, see "Sequence Numbering of Requests and 
Responses" in "Chapter 6.1. Data Flow Con- 
trol". 


SESSIONS WITH CRYPTOGRAPHY 


If session-level mandatory cryptography is 
selected when the session is activated, TC 
enciphers all FMD request RUs being sent and 
deciphers all those being received. The 
process of enciphering involves the following 
actions: 


e The RU is padded, when necessary, to an 
integral multiple of eight bytes. The 
padding bytes are added at the end and 
contain unpredictable values, except for 
the last pad byte, which contains an 
unsigned 8-bit binary count of the pad 
bytes. If only one byte of pad is 
required, that byte is the pad byte and 
it contains a 1. If padding is per- 
formed, the Padded Data indicator (PDI) 
in the RH is set to PD. 


° Prior to enciphering, the first eight 
bytes of an RU are exclusive-ORed with 
the session seed (i.e., the initial 
chaining value); the result is then enci- 
phered. Each subsequent 8-byte block 
within the same RU is exclusive-ORed with 
the output of the previously enciphered 
block. This technique is referred to as 
“block chaining with cipher text feed- 
back." When an enciphered RU is sent; 
the Enciphered Data indicator (EDI) in 
the RH is set to ED. 


®  Enciphering employs an 8-byte block chain 
algorithm and an 8-byte Key, the session 
cryptography key» and is in accordance 
with the Data Encryption Standard (DES) 
algorithm described in Federal Informa- 
tion Processing Standards Publication 46, 
dated January 15, 1977. 


The deciphering process is simply the inverse 
of enciphering. 


SESSION-LEVEL PACING 


Session-level pacing allows TC to control the 
rate at which it receives requests on the 
normal flow. If pacing is selected when the 
session 1s activated; all normal-flow 
requests are paced. Send pacing controls the 
outbound flow of data. Receive pacing con- 
trols the inbound flow of data. A TC.SEND 
performing send pacing has a session partner 
TC.RCV that is doing receive’ pacing. 
Requests and responses on the expedited flow 
are not paced and are unaffected by pacing on 
the normal flow. Pacing is generally used 
when the sending TC is capable of sending 
requests faster than the receiving TC can 
process them. 


The pacing environment assumes that = the 
receiving TC is able to accept no more than a 
certain number of requests (N) at a time. 
This number, called the window size, is 
defined when the session is being activated. 
Pacing operates according to the following 
cycle. The sending TC initially may send up 
to N requests. On the first request, it 
turns on the Pacing Request indicator. After 
the receiving TC receives the request that 
contains the Pacing Request indication, it 
can signal the sending TC (by using the Pac- 
ing Response indication) when it is ready to 
receive another group of requests. 


The sending TC Keeps a count of the number of 


requests that it can send before receiving a 
pacing response; this number is Kept in the 
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6.2-6 


pacing count field (SEND_PACING_COUNT). This 
field and =e all others related to 


session-level pacing or the maximum RU size 


are maintained in the transmission control 
control block (TCCB). The TCCB is a sub- 
structure of the control block named LOCAL. 
When a pacing response is received, the send- 
ing TC can send N more requests and therefore 
increases the pacing count by N. This makes 
the pacing count equal to the window size (N) 
plus the residual pacing count (the remaining 
requests not yet sent from the previous win- 
dow). If the pacing count drops to 0, the 
sender waits until a pacing response is 
received before sending any more requests. 
The value of the pacing count can range from 
0 to 2N-1. 


Only one pacing response is generated for 
each pacing request. There are two methods 
by which the pacing response may be returned: 
on a normal-flow response header or on an 
ISOLATED PACING RESPONSE (IPR). The IPR may 
be used at any time; however, it is especial- 
ly useful when no other response to a request 
is available in which to send the pacing 
response or when the available response is 
blocked on the pacing queue. IPR can be sent 
on the normal or expedited flow. 


TC.TRY_TO_SEND_IPR, which 
checks to determine 
should be 
half-session router (see "Chapter 6.0. 
Half-Session'). The decision on whether 
there are sufficient resources for sending a 
pacing response is implementation-dependent. 


includes all the 
if a pacing response 
sent, is 


Normal-flow responses that have the Queued 
Response indicator (QRI) set to QR are placed 
on the pacing queue, but do not cause the 
pacing count to be decremented when they are 
sent. When normal-flow responses indicate 
“QR, they can pass requests and responses 
marked QR at the queuing point in TC. If a 
request is held up by pacing, all responses 
marked QR and queued behind the request are 
also held up. | 


A Pacing Response indication is never added 
to a response held in Q@_PAC; it is added only 
to a response with QRI=QR as it is dequeued 
from Q PAC or to a response with QRI=-QR. If 
FSM_PAC_RQ SEND (page 6.2-20) is preventing 


the only available responses from flowing. 


from the queue, an IPR can be generated and 
sent directly to PC; this prevents session 
deadlock, which could occur when both TCs' 
pacing queues contain a request that cannot 
flow and that blocks the flow of the only 
available responses that might be used to 
carry the Pacing Response indication. 


In the BIND RU, four fields exist that define 
values for the send and receive window sizes 
of each stage of pacing. BIND also contains 
the staging indicators that specify one or 
two stages of pacing in the PLU-to-SLU direc- 
tion and in the SLU-to-PLU direction. 


invoked by the. 


If pacing on a session stage In a particular 
direction is not to be performed, the values 
for the window size on that stage are set to 
0. For example, if there is to be no pacing 
in the SLU-to-PLU direction, the PLU-receive 
and the SLU-send window sizes are both set to 
0. 


When a T2.1 node is sending a BIND to acti~ 
vate a session with an LU in an adjacent T2.1 
node, the PLU sets the staging indicators to 
specify one-stage in both directions, and 
sets the pacing window sizes to 
implementation-dependent values. When a sub- 
area node is sending a CP-mediated BIND, the 
values for the staging indicators and pacing 
windons are contained in the BIND image sent 
to the LU in CINIT, which the PLU way or may 
not place in the BIND RU. 


ISOLATED PACING RESPONSE (IPR) 


An IPR is sent by TC.TRY_TO_SEND_IPR (page 
6.2-19) to return a Pacing indication as dis- 
cussed in the preceding section. 


The following fields of the TH and RH are set 
for an IPR: 


TH: The normal or expedited flow is 
indicated. The sequence number is unde- 
fined (it may be set to any value, and it 
is not checked by the receiver). 
RH: IPRs are coded all 0's except for 
the Response indication, the Pacing 
Response indication, and the chaining 
bits; thus, the IPR RH is coded 
X'830100', and the test for an IPR is: 
RRI=RSP, ~DRI, -DR2, and PI=PAC. IPR is 
the only response that indicates both 
“DR1 and -DR2. | 


‘There is no RU accompanying the TH and RH. | 


REQUEST AND RESPONSE CONTROL MODES 


TC enforces the immediate request mode during 


CRYPTOGRAPHY VERIFICATION (CRV) exchange as 


part of TC initialization. The last thing 
that the primary I¢ does during initializa- 
tion is to send a CRV request and receive the 
CRV response. The last thing that the sec- 
ondary IC does during initialization is to 
receive the CRV request and send the CRV 
response. TC accepts no other records from 
HS components, and nothing from Path Control 
except CRV, during this time. 


TC is not involved in enforcing immediate 
request mode at any other time. , 


TC is not involved in inforcing immediate 
response mode at any time. 
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TRANSMISSION CONTROL CALLING TREES 


Figure 6.2-4 through Figure 6.2-6 show the 
calling trees for transmission control 
initialization and CRV exchange  § (Fig- 
ure 6.2-4), sending data (Figure 6.2-5), and 
receiving data (Figure 6.2-6). In addiiiton 


to the procedures in these calling trees, TC 
also contains TC.TRY_TO_SEND_IPR, a procedure 
that is called only by the half-session 
router, 


TC. INITIALIZE 
TC. EXCHANGE _ FSM_PAC_RQ_SEND}| |FSM_PAC_RQ_RCV 
CRV 
TC.BUILD_CRV| |TC.FORMAT_ 
CHECK 


Figure 6.2-4. TC Initialization Calling Tree 


TC. SEND 


TC.TRY_TO_| |FSM_PAC_RQ_SEND FSM_PAC_RQ_ 
ENCIPHER RCV 


Figure 6.2-5. SEND Calling Tree 


TC.RCV 
TC.RCV_ SEND_NEG_ FSM_Pac_ | |TC.RCV_ | |DFC_RCV| |TC.DEQUEUE_ 
CHECKS IRSP_OR_LOG*| {RQ_SEND NORM_RQ 3 PAC 


* See "Chapter 6.1. Data Flow Control" for details. 


Figure 6.2-6. RCV Calling Tree 
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FORMAL DESCRIPTION 


SESSION INITIALIZATION PROCEDURES 


6.2-8 


TC .INITIALIZE 


FUNCTION: 


INPUT: 


Sets up session parameters needed by TC. This procedure is called by 
half-session initialization (see Chapter 6.0 ) when the session is being acti- 
vated. The TCCB (a substructure of LOCAL) is initialized according to whether 
this 1s a primary or secondary LU-LU half-session or a CP-LU half-session. 
The maximum receive RU size is initialized. 


INIT_HS is a structure that indicates whether the type of session to initial- 
ize is an LU-LU session or a CP-LU session. For LU-LU sessions, the INIT_HS 
record contains BIND information. For CP-LU sessions, the INIT_HS record con- 
tains ACTLU information. The BIND or ACTLU information contains the values to 
which the fields of the TCCB will be initialized. The TS and FM profiles, the 
identifier of the path control with which this half-session is associated, the 
role (primary or secondary) of the half-session, and LOCAL.SENSE_CODE are ini- 
tialized prior to calling this procedure. Caller checks that the TS profile 
is lor 7. 


The correct initialization procedure is executed. <A variable indicating that 
initialization was SUCCESSFUL or UNSUCCESSFUL is set. 


Referenced procedures, FSlis, and data structures: 


TC. EXCHANGE_CRV page 6.2-10 
FSM_PAC_RQ_SEND page 6.2-20 
FSM_PAC_RQ_RCV page 6.2-21 
LOCAL page 6.0-6 
INIT_HS page A-16 


Initialize the half-session according to the TS profile (see Appendix F) and the session 
activation RU (see Appendix E). The procedure has access to the INIT_HS record 
and the LOCAL control block. 
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TC. INITIALIZE 


If CP-LU half-session then 
see TS profile 1 and the ACTLU RU. Record the following information: 
® Maximun RU size that can be received (obtained frow the INIT_HS.ACTLU_IMAGE), 
converted from exponent/mantissa form to binary form (see BIND in Appendix E 
for the conversion table). The maximum RU size parameter is not part of 
the ACTLU RU, but is initialized by UNS and passed in the ACTLU_IMAGE 
® That identifiers are used 
That neither send nor receive pacing is active 
® That cryptography is not active 


Else (LU-LU sessions--see TS profile 7 and the BIND RU) 
Record the following information: 
® Maximum RU size sent by the partner half-session on the normal flow, 
(obtained from the INIT_HS.BIND_IMAGE), converted from exponent/mantissa 
form to binary form 
® That sequence numbers are used 
® For a primary half-session, 
e Whether send pacing is active, and, if so, the primary send window size 
e Whether receive pacing is active, and » if so, the primary receive window size 
® For a secondary half-session, 
e¢ Whether send pacing is active, and, if so, the secondary send window size 
 @ Whether receive pacing is active, and, if so, the secondary receive window size 
e Whether cryptography is active 


If the BIND_IMAGE indicates that cryptography is active then 
Call TC.EXCHANGE_CRV( INIT_HS.BIND_IMAGE) (page 6.2-10) to participate in 
cryptography verification. (The BIND image and the CRV format are found in 
Appendix E.) 
If cryptography verification is unsuccessful (LOCAL.SENSE_CODE # 0) then 
Return with a value of UNSUCCESSFUL. 

Call FSM_PAC_RQ_SEND (page 6.2-20) and FSM_PAC_RQ_RCV (page 6.2-21), passing 
thea RESET signals. 

Purge the pacing queue (LOCAL.Q_PAC), set the send and receive pacing counts 
( LOCAL.SEND_PACING_COUNT and LOCAL.RCV_PACING_COUNT) to the values of the 
corresponding window sizes, and initialize the receive sequence rumber 
(LOCAL.SQN_RCV_CNT) to 0. 

Return with a value of SUCCESSFUL. 
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TC. EXCHANGE_CRV 


TC..EXCHANGE_CRV 


FUNCTION: Called from a primary half-session to initiate the exchange of CRV with a sec- 
ondary and to receive RSP(CRV). Called froma secondary half-session to 
receive CRY and return RSP(CRV) to the primary. 


INPUT: BIND image (received in RSPIBIND)]) contains the enciphered pseudo-random value 
to be used as a test value (and later as the session seed). This value is 


enciphered using the session Key as the cryptography key and 0 as the initial 
chaining value. 


The initialization of a secondary TC instance involves receiving a 

PC_TO_HS_RECORD containing a CRV request, and the initialization of a primary 

TC instance involves receiving a PC_TO_HS_RECORD containing a CRV response. 
OUTPUT: CRV exchange completed. If successful, LOCAL.SENSE_CODE = 

The initialization of a secondary TC instance involves sending an 


HS TO_PC_RECORD containing a CRV response, and the initialization of a primary 
TC instance involves sending an HS_TO_PC_RECORD containing a CRV request. 


Referenced procedures» FSMs, and data structures: 


TC .FORMAT_CHECK page 6.2-11 
TC BUILD _CRV page 6.2-1l1 
Pc Not shown in this book 
LOCAL 7 page 6.0-6 
PC_TO_HS_RECORD page A-23 
HS_TO_PC_RECORD page A-11 


If primary half-session then 
Call TC.BUILD_CRV(BIND_IMAGE,BIU) (page 6.2-11) to build a CRV request BIU, 
including the appropriate PIU fields. 
Incorporate the BIU into the PIU field of the HS_TO_ PC_ RECORD (see page 6.2-13). 
Send the HS_TO_PC_RECORD to the path control (PC) that the half-session uses. 
Receive a PC_TO_HS_RECORD from path control. This implies a possible wait. 
Extract the BIU from the PIU field of the PC_TO_HS_RECORD. 
If not a CRV response then 
Set LOCAL.SENSE_CODE to X'20090000' (SC protocol error). 
Else (CRV response) 
Optionally, call TC.FORMAT_CHECK(BIU) (page 6.2-11) to verify the RH. 
If the format checked out OK then 
If RTI = NEG then 
Set LOCAL.SENSE_CODE to the sense data value in the BIU. 
Else (secondary half-session) 
Receive a PC_TO_HS_RECORD from path control. This implies a possible mait. 
Extract the BIU from the PIU field of the PC_TO_HS_RECORD. 
If that received record is a CRV request then 
Optionally call TC.FORMAT_CHECK(BIU) (page 6.2-11) to verify the RH. 
If the format checked cut OK then 
Check that the CRV test value was correctly encoded by the session partner by: 
deciphering the test value (bytes 2-9 of the RU data) using the session key 
and 0 as the initial chaining value, inverting the bits 
in the first 4 bytes, and comparing the a mith the value that was 
generated by LNS for the #RSP(BINOD). 
If the values are equal then 

Incorporate a positive response into the PIU field of the HS_TO_PC_RECORD. 

See page 6.2-13 for details on constructing the HS_TO_PC_RECORD. 

Send the HS_TO_PC_RECORD to the path control that the half-session uses. 

Else (values not equal) 

Set LOCAL.SENSE_CODE to X'08350001' (Invalid Parameter). 
(LOCAL.SENSE_CODE now has a value of nonzero, so the half-session router 
will cause UNBIND to be sent.) 

Else (RH not valid) 
(LOCAL.SENSE_CODE already has a value of nonzero, so the half-session 
router will cause UNBIND to be sent.) 
Else (not CRV request) 
Set LOCAL.SENSE_CODE to X'20090000' (SC protocol error). (LOCAL.SENSE_CODE 
now has a value of nonzero, so the half-session router will cause UNBIND 
to be sent.) 
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TC.BUILD_CRV 


FUNCTION: This procedure builds a CRV BIU by appropriately assigning the RH and RU 
fields. 


INPUT: BIND information and BIU to be initialized. The test value sent in CRV is 
derived from the BIND image. 


OUTPUT: The CRV PIU, including the TH settings for EFI and SNF. The session 
cryptography seed is retained. 


NOTE: For the actual TH and RH bit settings see Appendix D . 


Set EFI to EXP. 

Set SNF to some value (implementation-dependent). CRV is on the TC-TC flow, 

not the half-session to half-session flow, so is not related to the half-session 
send sequence number (LOCAL.SQN_SEND_CN7). 


Set the RH to the following values: 
(RQ, Sc, FMH “SD, BC, EC; RQDI1, “QR, “PAC, ~BB, “CD, CODEO, “ED, “PD, “CEB). 


Set the RU data to CRV request code (see page A-33). 
Prepare the cryptography test value: 

Decipher the test value in the BIND image, which is in the INIT_HS record. 

Use the session cryptography Key that was received from the CP in the CINIT 

request as the cryptography key, and 0 as the initial chaining value. 

See the Data Encryption Standard for details. Retain the resulting value 

for use as the session seed. Transform the result by inverting each bit 

of the first four bytes and enciphering the transformed value (use the session 

Key as the cryptography key and 0 as the initial chaining value). 

Append this transformed test value to the RU data. 


TC. FORMAT_CHECK 


FUNCTION: Checks the RH bits of the request or response. All of these checks 
optional. An implementation may choose to do all, some, or none of them. 


INPUT: A request or response BIU. 


OUTPUT: OK if all bits are properly set; otherwise, NG. If NG, LOCAL.SENSE_CODE is 
set to a nonzero value. 


Referenced procedures, FSMs, and data structures: 
LOCAL page 6.0-6 
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TC. FORMAT_CHECK 


If EFI #* EXP then 
Set LOCAL.SENSE_CODE to X'40110000’. 
Else (expedited BIU) 
If RRI = RQ then 
Select in the following order, based on the RH bits: 
When (SDI # SD and RU_LENGTH < 1) or 
(SDI = SD and RU_LENGTH < 5) 
Set LOCAL.SENSE_CODE to X'10020000'. 
When FI * FMH 
Set LOCAL.SENSE_CODE to X'400F0000'. 
When SDI = SD 
Set LOCAL.SENSE_CODE to the sense data in the BIU. 
When BCI # BC 
Set LOCAL.SENSE_CODE to X'400B0000'. 
When ECI # EC 
Set LOCAL.SENSE_CODE to X‘'400B0000'. 
When response category # RQD1 
Set LOCAL.SENSE_CODE to X'40140000'. 
When QRI = QR 
Set LOCAL.SENSE_CODE to X‘'40150000'. 
When PI = PAC 
Set LOCAL.SENSE_CODE to X'40080000'. 
When BBI = BB 
Set LOCAL.SENSE_ CODE to X'400C0000'. 
When EBI = EB 
Set LOCAL.SENSE_ CODE to X'400C0000'. 
When CDI = CD 
Set LOCAL.SENSE_CODE to X'400D0000'. 
When CSI = CODE1 
Set LOCAL.SENSE_CODE to X'40100000'. 
When EDI = ED | 
Set LOCAL.SENSE_CODE to X'40160000'. 
When POI = PD 
Set LOCAL.SENSE_CODE to X'40170000'. 
When CEBI = CEB 
Set LOCAL.SENSE_CODE to X'400C0000'. 
Else (response) 
Select in the following order, based on RH bits: 
When (RTI = POS and RU_LENGTH < 1) or 
(RTI = NEG and RU_LENGTH < 5) 
Set LOCAL.SENSE_CODE to X'10020000'. 
When FI # FMH 
Set LOCAL.SENSE_CODE to xX'400F0000'. 
When BCI # BC 
Set LOCAL.SENSE_CODE to X'400B0000'. 
When ECI # EC 
Set LOCAL.SENSE_CODE to X'400B0000'. 
When DRII * DR1 
Set LOCAL.SENSE_CODE to X'40140000'. 
When DR2I = DR2 
Set LOCAL.SENSE_CODE to X'40140000'. 
When (RTI = POS and SDI = SD) or 
(RTI = NEG and SDI = NOT_SD) 
Set LOCAL.SENSE_CODE to X'‘'40130000'. 
When QRI = QR 
Set LOCAL.SENSE_CODE to X'4$0150000'. 
When PI = PAC 
Set LOCAL.SENSE_CODE to X'40080000'. 
If LOCAL.SENSE_CODE = 0 (no error) then 
Return with a value of OK. 
Else (format error) 
Return with a value of NG. 
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TC. SEND 


FUNCTION: Send the input BIU to path control. If required, the message unit is enciI- 
phered. If pacing is supported, the message unit may be placed on Q_PAC rath- 
er than sent directly to path control. 


BIU along with the EFI and SNF. (The RH, and the RU were set up by the proce- 
dure that passed this record to TC); whether send pacing is active; whether 
receive pacing is active; and the send pacing count (LOCAL.SEND_PACING COUNT) 


if send pacing is active. 


OUTPUT: If no errors, BIU is sent to PC or placed on Q_PAC. The Pacing indicator is 
set to specify whether or not the BIU is a pacing request or response. If 
send pacing is active, LOCAL.SEND_PACING_COUNT is decremented. 
LOCAL.SENSE_CODE = QO. 


If any errors are detected, a nonzero sense code is returned to the caller in 
LOCAL.SENSE_CODE. 


Referenced procedures, FSMs, and data structures: 


TC.TRY_TO_ENCIPHER page 6.2-14 
PC Not shown in this book 
FSM_PAC_RQ_ SEND page 6.2-20 
FSM_PAC_RQ_RCV page 6.2-21 
LOCAL page 6.0-6 
HS_TO_PC_RECORD page A-11 


Initialize PI to -PAC. 
Select in the following order, based on RRI and EFI RH bits: 


When EFI = EXP 
Indicate that the pacing queue does not need to be checked. 


When RRI = RQ 
If send pacing is active then 
Indicate that the pacing queue needs to be checked. 
Else (send pacing not active) 
Indicate that the pacing queue does not need to be checked. 
Call TC.TRY_TO_ENCIPHER(BIU) (page 6.2-14) to encipher the BIU. 
LOCAL.SENSE_CODE will be nonzero if enciphering failed. 


When RRI = RSP 
If send pacing 1s active and QRI = QR and the pacing queue (LOCAL.Q@ PAC) 
is not empty then 
Indicate that the pacing queue needs to be checked. 
Else 
Indicate that the pacing queue does not need to be checked. 
If receive pacing is active and FSM_PAC_RQ_RCV (page 6.2-21) 
is in the PEND state and there are sufficient Cimplementation-dependent ) 
resources then 
Call FSM_PAC_RQ RCV(BIU) (page 6.2-21) to manipulate the Pacing 
indicator in this response. 
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TC .SEND 


6.2-14 


If LOCAL.SENSE_CODE = 0 then 


pera based on whether the pacing queue should be checked (as indicated 
above ); 


When YES 
If RRI = RQ and LOCAL.SEND_PACING_COUNT > 0 then 
Call FSM_PAC_RQ_SEND(BIU) (page 6.2-20).-to record the ability 
to send a session-level pacing request for send pacing. 
Decrement LOCAL. SEND_PACING_COUNT by 1. 
Incorporate the BIU into the PIU field of the HS_TO_PC_RECORD: 
_ Set the HS_ID to the identifier of the half-session that 
is sending this record. 
(EFI, SNF, the RH, and the RU were set up by the procedure that 
passed this record to TC.) 
Set DCF to the length of the RH plus the length of the RU. 


Send the HS_TO_PC_RECORD to the path control (PC) that the half-session 
uses. 


Else (not normal flow or send pacing count < 0) 
Enqueue the BIU to the end of the pacing send queue (LOCAL.Q_PAC). 


When NO 


Incorporate the BIU into the PIU field of the HS_TO_PC_RECORD 
(see above): 


Send the HS_TO_PC_RECORD to the path control that the half-session uses. 


Else (cryptography error) 


(The half-session router will cause the session to be terminated because 
LOCAL.SENSE_CODE is nonzero. ) 


TC. TRY_TO_ENCIPHER 


FUNCTION: Encipher a normal-flow request if necessary. 


|. INPUT: A BIU that includes a normal-flow request from TC.SEND3; indicator of whether 
cryptography is active for the session; the cryptography session key and ses- 
sion seed (the technique for providing the cryptography session key and ses- 
sion seed is defined by the implementation). 


OUTPUT: If necessary, BIU is enciphered and padded, and EDI and POI are set according- 
ly. 


Referenced procedures, FSMs, and data structures: 


LOCAL page 6.0-6 


If the RU category is FMO and the RU data length > 0 
and cryptography is active then 


If the RU length is not an even wultiple of & then 
Pad the RU to an integral number of eight bytes. The padding bytes are 
added to the end and contain unpredictable values, except for the last 
pad byte, which contains an unsigned 8-bit binary count of the pad bytes 
preceding it. If only one byte of pad is required, it is the count byte 
itself and contains 1. 
Set PDI to PD. 

Else 
Set POI to -PD. 


Encipher the RU data: 
Execute the Data Encryption Standard (DES) algorithm, using the session Key 
as the cryptography key and the session seed as the initial chaining value. 
The manner in which the session key and the session seed are made available 
to this procedure is implementation-defined. Details of the DES algoritha 
are not formally specified in this book. 
If enciphering fails then 

Set LOCAL.SENSE_CODE to X'08480000' nave ee ain function inoperative). 
Else 

Set EDI to ED. 
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TC .RCV 


Receive message units sent to the half-session by PC. The usage and state 
checks are made. If the message unit contains a pacing response, it is proc- 
essed. Requests and responses are routed and pacing requests are processed. 
Sequence numbers are processed. 


A request or response BIU from the half-session router (see Chapter 6.0). 


If no errors, DFC.RCV is called to process the BIU. If an error is encount- 
ered for CP-LU sessions, a negative response is generated. If an error is 
encountered for LU-LU sessions, LOCAL.SENSE_CODE is set to a nonzero value and 
the half-session router causes an UNBIND to be generated. 


If the BIU is an Isolated Pacing Response (IPR) it is discarded. 


Referenced procedures, FSMs, and data structures: 


TC.RCV_CHECKS page 6.2-16 
TC ..RCV_NORM_RQ page 6.2-17 
DFC_RCV page 6.1-23 
SEND_NEG_RSP_OR_LOG page 6.1-37 
LOCAL page 6.0-6 
PC_TO_HS_RECORD page A~23 


This procedure has access to the PC_TO_HS_RECORD and to the LOCAL control block. 
Extract the BIU from the PIU field of the PC_TO_HS_RECORD. 


Call TC.RCV_CHECKS(BIU) (page 6.2-16) to check for 
errors in the received BIU. 
If there is a receive check error (LOCAL.SENSE_CODE # 0) then 
If this is an LU-LU session then 
(The nonzero setting of LOCAL.SENSE_CODE causes an UNBIND to terminate 
— the session.) 
Else (CP_LU session) 
Call SEND_NEG_RSP_OR_LOG(BIU) (page 6.1-37) to send a negative 
response or to log the error. 


Else (no receive-check errors) 
If send pacing is active then 
If RRI=RSP and PI=PAC then 
Call FSM_PAC_RQ_SEND(BIU) (page 6.2-20) to record the ability to send 
@ pacing request for send pacing. 
Call TC.DEQUEUE_PAC (page 6.2-18) to remove BIUs from tha 
send pacing queue (LOCAL.Q PAC). 


If RRI=RSP and PI=PAC and DRIIZDR1 and DR2IZDR2 (it is an IPR) then 
Discard the IPR. 
Else (not IPR) 
If EFI = NORMAL and RRI = RQ then 
Call TC.RCV_NORM_RQ(BIU) (page 6.2-17) to decipher the RU data (if necessary), 
update the receive pacing FSM, and increment the last received sequence 
number CLOCAL.SQN_RCV_CNT). 
If LOCAL.SENSE_CODE = 0 then 
Call DFC_RCV(BIU) (page 6.1-23) to pass the record to DFC. 
Else 
(The nonzero setting of LOCAL.SENSE_CODE causes an UNBIND to terminate 
an LU-LU session. ) 
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TC.RCV_CHECKS 


6.2-16 


TC.RCV_CHECKS 


FUNCTION: Usage checks are made for valid RU length and valid sequence number on a 
normal-flow request. If cryptography is to be used, an optional check is made 
that EDI is set when enciphering is mandatory, and tha length of the RU is 
checked for being a multiple of 8. An optional check is made that the pacing 
protocol was not violated by the sender. The procedure verifies that all FSis 


are in the proper state. 


INPUT: A request or response BIU from TC.RCV; indication whether maximum receive RU 


size is being enforced, and the maximum receive RU size 


CAL.MAX_RCV_RU_SIZE) if so; indication whether sequence mmbers are being 
used, and the last receive sequence number if so; indication whether receive 
pacing is active, and the receive pacing count (LOCAL.RCV_PACING_COUNT) if so; 


indication whether cryptography is active. 


OUTPUT : If a problem is found, LOCAL.SENSE_CODE is set to nonzero. 


Referenced procedures, FSits, and data structures: 
LOCAL | ee 2 page 6.0-6 


If RRI = RQ and SOI = SD then 
Return with LOCAL.SENSE_CODE set to the sense code of the BIU. 


If EFI = NORMAL then 
If a maximum receive RU size was specified at session activation and 
the length of the received RU > maximum receive RU size then 
Return with LOCAL.SENSE_CODE set to X'10020000' (RU length error). 
If RRI = RQ then 
If sequence numbers are being used then 
If SNF # next expected sequence number (LOCAL.SQN_RCV_CNT + 1) 
(including consideration of the wrap case) then 
Return with LOCAL.SENSE_CODE set to X'20010000' (sequence number error). 
If PI = PAC but receive pacing is not active then 
Return with LOCAL.SENSE_CODE set to X'40080000' (pacing not supported). 


If cryptography is active and the RU category is 
FMD and the length of the RU > 0 then 
If EDI = ~ED then 


Return with LOCAL.SENSE_CODE set to X'08090000' (mode inconsistency). 
Else (enciphered) 


If the RU data length is not an even multiple of 8 bytes then 
Return with LOCAL.SENSE_CODE set to X'10010000' (RU data error), 


(The following is an optional check for pacing protocol violation) 
If receive pacing is active and the receive pacing count (LOCAL.RCV_PACING_COUNT) 
= 0 then 

Return with LOCAL.SENSE_CODE set to X'20110000' (pacing error). 


If the RU category is network control or session control then 
Return with LOCAL.SENSE_CODE set to X'10070000' (category not supported). 


Return with LOCAL.SENSE_CODE set to 0 (no errors). 
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TC .RCV_NORM_RQ 
TC.RCV_NORM_RQ 


Decipher a normal-flow request if necessary, update receive pacing FSM, and 
increment sequence number. 


Normal-flow request BIU; indication whether cryptography is active; indication 
whether sequence numbers are used, and, if so, the last received sequence num- 
ber (LOCAL.SQN_RCV_CNT)3 indication whether receive pacing is active, and, if 
SO» the receive pacing count (LOCAL.RCV_PACING_COUNT); the session 
cryptography Key and seed. 


Normal-flow request deciphered if input was enciphered. If sequence numbers 
are used, the sequence mumber is updated. If receive pacing is active, the 
receive pacing count is decremented. 


Referenced procedures, FSMs, and data structures: 
FSM_PAC_RQ_RCV page 6.2-21 
LOCAL page 6.0-6 
If cryptography is active and the RU category is FMO and the RU data 
length > 0 then ™ 
Execute the DES decipher algorithm. Use the session key as the cryptography key. 
Use the session seed as the initial chaining value. The manner in which 
the session key and the session seed are made available to this procedure 
is implementation-defined. Details of the DES algorithw are not formally 
specified in this book. 
If deciphering is not successful then 
Set LOCAL.SENSE_CODE to X'08480000' (cryptography function inoperative). 
Log the error. 
Else (deciphering was successful) 
If PI = PAD then 
If the pad count is less than 1 or greater than 7 then 
Set LOCAL.SENSE_CODE to X'10010000', RU data error. 
Log the error. 
Else 
Eliminate the padding. Set PI to ~PAD. 


If sequence numbers are being used then 
Increment the last received sequence number (LOCAL.SQN_RCV_CNT) by 1, tncluding 
handling the wrap condition. 


If receive pacing is active then 
Call FSM_PAC_RQ_RCV(BIU) (page 6.2-21) to record the ability to send a session 
pacing response for receive pacing. 
Decrement the receive pacing count (LOCAL.RCV_PACING_COUNT) by 1. 
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TC.DEQUEUE_PAC 


FUNCTION: A pacing response has been received so Q@ PAC is now unlocked. Determine if it 
is valid to remove a BIU from Q_PAC. It is valid to remove a BIU from Q_PAC 
if it is a response or if it is a request and the pacing count is nonzero. 


If valid, removes BIU from Q_PAC and sends it to path control. This procedure 
may cause the Pacing indicator in the BIU to be set to PAC. 


INPUT: LOCAL.Q_PAC has BIUs that were not sent earlier because a pacing response was 
outstanding; state of FSM_PAC_RQ_ RCV; the send = pacing count (LO- 
CAL.SEND_PACING_COUNT). 


OUTPUT: HS_TO_PC_RECORD is sent to path control. 


NOTE: Procedure called only if LOCAL.SEND_PACING = YES. 


Referenced procedures, FSMs, and data structures: 


FSM_PAC_RQ_SEND | page 6.2-20 
FSM_PAC_R@Q_ RCV | page 6.2-21 
PC Not shown in this book 
LOCAL page 6.0-6 
HS_TO_PC_RECORD | page A-11 


Do while LOCAL.Q_PAC is not empty and (send pacing count [ LOCAL. SEND_PACING_ COUNT] > 0 
or the top entry on Q_PAC is a response) 

Remove the first enqueued BIU from Q_PAC. 

Select, based on the RRI of the removed BIU: 


When RRI = RQ 
CALL FSM_PAC_RQ_SEND(removed BIU) (page 6.2-20) to manipulate the PI 
in the BIU being sent and to manage send pacing states. 
Decrement the send pacing count (LOCAL.SEND_PACING_COUNT) by 1. 


When RRI = RSP 
If sufficient (implementation-dependent) resources exist and FSM_PAC_RQ_ RCV 
(page 6.2-21) is in the PEND state and receive pacing is active then 
CALL FSM_PAC_RQ_RCV( removed BIU) (page 6.2-21) to manipulate 
the PI in the BIU being sent and to manage receive pacing states. 


Incorporate the BIU into the PIU field of the HS_ TO_PC_RECORD (see page 6.2-13 
for details). 

(EFI, SNF, the RH» and the RU data were set up by the process that originally 
passed this record to TC.) | 

Send the HS_TO_PC_RECORD to the path control (PC) that the half-session uses. 
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TC.TRY_TO_SEND_IPR 


FUNCTION: Determines if an ISOLATED PACING RESPONSE (IPR) may be sent, based on the 


state of FSM_PAC_RQ RCV (page 6.2-21) and the availability of resources. If 
an IPR may be sent, the procedure generates an ISOLATED PACING RESPONSE 
(RH=X'830100') and sends it to path control. 


INPUT: An indication whether receive pacing is active for the session; state of the 


FSM PAC_RQ RCV. 


OUTPUT: If an IPR is allowed, an ISOLATED PACING RESPONSE is sent to path control. 


NOTE : 


1) An IPR is unique because it is the only response that can be sent with DRII 
and DR2I off (response category = RQN). 


2) When an implementation sets the return code to NG, a method must be pro- 
vided to insure that the half-session router will execute again when resources 
become available. Otherwise, the session could deadlock. 


IPRs are needed to prevent deadlocks when no responses are being sent that can 
carry the pacing response or when the only available responses are blocked on 
the pacing queue. IPRs cannot be blocked on the pacing queue. 


This routine is called periodically by the half-session router (see Chapter 
6.0). 


Referenced procedures, FSMs, and data structures: 


FSM_PAC_RQ RCV page 6.2-21 
PC Not shown in this book 
LOCAL page 6.0-6 


If receive pacing is active and the state of FSM_PAC_RQ_RCV(BIU) (page 6.2-21) 
is PEND then 


If 


Els 


sufficient (Cimplementation-dependent) resources exist then 
Create a BIU to contain the IPR. 


Set EFI to NORMAL or EXP (either normal or expedited flow is valid). 


Set SNF to some value (implementation dependent). IPR is on the TC-TC flow, 
not the half-session to half-session flow, so is not related to the half- 
session send sequence number (LOCAL.SQN_SEND_CNT). 


Set DCF to the length of the RH plus the length of the RU. 


Set the RH to X'830100': 

(RSP, FMD, -FMH, ~SD, BC, EC, RQN, POS, ~DR1, -DR2, -QR, PAC, 

“BB, -CD, CODEO, ~ED, -~PD, ~CEB). 
Set the RU to the null value. 
Call FSM_PAC_RQ_RCV(BIU) (page 6.2-21) to manage receive pacing. 
Incorporate the BIU into the PIU field of the HS_TO_PC_RECORD. 
Send the HS_TO_PC_RECORD to the path control (PC) that the half-session uses. 
e 
NOTE: When the implementation does not have sufficient resources at this 
time, a method must be provided to insure that the half-session router 
will execute again when resources become available. Otherwise, the session 
could deadlock. 
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TC FINITE-STATE MACHINES 


6.2-20 


FSM_PAC_RQ_SEND 


FUNCTION: Records the ability to send a_ session-level pacing request for send pacing. 
RESET state indicates that a pacing request can be sent. AWAITING indicates 
that a pacing request has been sent but no pacing response has been received. 


BIU; send pacing count (LOCAL.SEND_PACING_COUNT). 


S, RQ, FIRST_IN_WINDON means sending a BIU with RRI=RQ when the send pacing 
count equals the send window size. 


S, RQ, ~FIRST_IN_WINDOW means sending a BIU with RRI=RQ, when the send pacing 


count does not equal the send window size. 
R, RSP, PAC means receiving a BIU with RRI=RSP and PI=PAC. 
OUTPUT: PI, LOCAL.SEND_PACING_COUNT. 


NOTE: FIRST_IN_WINDOW is TRUE when the pacing count equals the window size. This is 
never true when the FSM 1s in the ANAITING state because when the FSM enters 
the AWAITING state, the pacing count is set to 1 less than the window size. 
The pacing count is increased only when a pacing response is received, at 
which time the FSM returns to the RESET state. 


Referenced procedures, FSMs, and data structures: 
LOCAL page 6.0-6 


STATE NAMES----> RESET AWAITING 
INPUTS STATE NUMBERS~--> 01 02 
S, RQ, FIRST_IN_WINDOW 2(PACRQ) /NOTE 
| S» RQ, ~FIRST_IN_WINDOW -(NOPAC ) -~(NOPAC ) 
R, RSP, PAC ~(PACERR ) 1( PACRSP ) 


OUTPUT | FUNCTION 
CODE 


PACRQ Set PI to PAC. 
NOPAC Set PI to ~PAC. 


PACERR Set PI to -PAC. 
Log the unexpected pacing response that was received. 


7 PACRSP Increase the send pacing count (LOCAL.SEND_PACING_COUNT ) 
by the value of one send window (specified at session activation). 
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FSM_PAC_RQ_RCV 


FSM_PAC_RQ RCV 


FUNCTION: Records the ability to send a session pacing response for receive pacing. In 
RESET state, no pacing response is sent; in PEND state, 1t is. 


In PEND state this half-session has resources to receive another window of 
BIUs but there has not been a response flowing on which to indicate the condi- 
tion. The half-session is looking for a response to be sent. 


When a pacing response is sent, the receive-pacing count is incremented by the 
receive-pacing window size. The receive-pacing count field is required only 


for an optional receive check. 

Receive pacing count (LOCAL.RCV_PACING_ COUNT). 

R, RQ, PAC means receiving a BIU with RRI=RQ and PI=PAC. 
S, RSP means sending a BIU with RRI=RSP. PI must be ~PAC. 


OUTPUT: PI may be set to PAC or ~PAC; LOCAL.RCV_PACING COUNT may have been incremented 
by window size. 


Referenced procedures, FSMs, and data structures: 
LOCAL page 6.0-6 


INPUTS STATE NUMBERS-->| 01 02 
SIGNAL( RESET) | =... he 


OUTPUT | FUNCTION 
CODE 


PAC Set PI to PAC. 
Increase the receive pacing count (LOCAL.RCV_PACING_COUNT) 
by the value of one receive window (specified at session activation). 


PACERR Set PI to -PAC. 
| Log the unexpected pacing request that was received. 
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APPENDIX A. NODE DATA STRUCTURES 


This appendix contains the shared data struc- 
tures for LU 6.2. 


CPLU_CB 


The CP-LU control block represents an active session between this LU and a control point 
(SSCP or PNCP). 


CPLU_CB 
CP_ID: control point identifier (see page A-2) 
PC_ID: identifier of path control being used by this CP-LU session 
HS_ID: identifier of the CP-LU half-session 


LUCB 
The LUCB_LIST contains information about LUs. There is one LUCB_LIST per node and one 
LUCB per LU. 


The LUCB_LIST is created at systew-definition time. The initial values of the fields in 
each LUCB entry are implementation-speci fic. 


NOTES: 1. Fully-qualified LU names consist of type-A symbol strings. Transaction pro- 
gram names consist of type-AE up through type-GR symbol strings,» depending on 
the implementation. See "Appendix E. Request/Response Unit (RU) Forwats" for 
symbol-string definitions. 


If the LU name is not present, the FULLY _QUALIFIED_LU_NAME field is null. 
Subarea LUs, LUs doing sync point, and LUs using parallel sessions have to 
know their own names. 


The FULLY_QUALIFIED_LU_NAME contains no trailing blanks. 


LUCB 


Shared Data 


LULID: identifier of the local LU 

FULLY, QUALIFIED_LU_NAME (see Notes ) 

PARTNER_LU_LIST (see page A-2) 

“TRANSACTION _PROGRAM_LIST: (see page A-4) 

PENDING_RANDOM_DATA_LIST: list of randow data that has been sent on a 
BIND to a partner 


Data Unique to PS.COPR 


LU_SESSION_LIMIT: waximum number of LU-LU sessions the local LU can have 
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cP_ID 


CP_ID 


The CP_ID structure is the unique control point (e.g., SSCP, PNCP) identifier. 


CP_ID 
Subarea node contents: 
CP_NETWORK_ADDRESS: full network address of control point 
Peripheral node contents: 


ALS: adjacent link station that control point is using for CP-LU and CP-PU sessions 


PARTNER_LU 


The PARTNER_LU_LIST is a list contained within each LUCB entry. There is one PART- 
NER_LU_LIST per LU and one PARTNER_LU entry for each LU name known by a given LU. Each 
PARTNER_LU entry contains information that is LU name specific (i.e., inforwation that is 
constant across all mode names for a given LU name). 


The PARTNER_LU_LIST is created at system-definition time. The initial values of the 
fields in each PARTNER_LU entry are implementation specific. 


NOTES: 1. The (partner) LOCAL_LU_LNAME is the name that a transaction program specifies 
in conjunction with the MODE NAME when requesting the allocation of a conver- 
sation. It is a local name by which one LU Knows another LU and is not sent 
outside the LU. The waximusa length of the LU_NAME is implementation-defined. 


There may be an entry in the PARTNER_LU_LIST whose LOCAL _LU_NAME is the same 
as the LU name of this LU. This allows for cases when the remote transaction 
program is located in the same LU as the local program. 


2. Local LU names consist of type-G symbol strings. Fully-qualified LU names con- 
sist of type-A symbol strings. See "Appendix E. Request/Response Unit (RU) 
Formats" for symbol-string definitions. 


3. The (partner) FULLY_QUALIFIED_LU_NAME is the LU name that is sent on external 
flows; e.g. b ] BIND. 


4. The LOCAL_LU_LNAME, FULLY_QUALIFIED_LU_NAME, and UNINTERPRETED_LU_NAME fields 
contain no trailing blanks. 


PARTNER_LU 


Shared Data 


LOCAL_LU_NAME (see Notes 1, 2, and 4) 
FULLY_QUALIFIED_LU_NAME (see Notes 2, 3, and 4) 
UNINTERPRETED_LU NAME (see Note 4) 

MODE_LIST (see page A-~-3) 
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MODE 


MODE 


The MODE_LIST is a list contained within each PARTNER_LU entry. There is one MODE entry 
in the MODE_LIST for each mode name that is associated with PARTNER_LU.LOCAL_LU_NAME. 
Each MODE entry contains mode-name specific information. 


The MODE_LIST is created at system-definition time. The initial values of the fields in 
each MODE entry are implementation specific. 


NOTES: 1. The WAITING_REQUEST_LIST contains requests for sessions sent by PS.CONV 
("Chapter 5.1. Presentation Services--Conversation Verbs") that the resources 
manager cannot presently fulfill because no free sessions are available. 
Entries are removed from the list when an existing session becomes free or 
when a new session is activated. 


2. The FREE_SCB_LIST is a list of sessions that are currently not itn use by any 
conversation. The list is an ordered list in that all = first-speaker 
half-sessions are grouped at the front of the list with all bidder 
half-sessions following. <A new first-speaker entry is inserted at the begin- 
ning of the list, while a new bidder entry is inserted at the end. 


The FREE_SCB_LIST and the WAITING _REQUEST_LIST are mutually exclusive. An 
entry in the FREE _SCB_LIST precludes there being an entry in the WAIT- 
ING_REQUEST_LIST, and vice versa. 


3. Mode names consist of type-A symbol strings. See "Appendix = E. 
Request/Response Unit (RU) Formats" for symbol-string definitions. 


G@. TERMINATION_COUNT is the cout of the number of sessions that this LU is 
responsible for deactivating. PENDING_TERMINATION_® counts sessions that are 
pending termination. A session is pending termination from the time that RM 
("Chapter 3. LU Resources Manager") sends BIS(RQE1) or BIS(RQE3) to the time 
that the LU resources manager sends DEACTIVATE_SESSION or receives SES-~ 
SION_DEACTIVATED. 


5. ACTIVE _* COUNT counts active sessions. These counts are maintained by RM 
("Chapter 3. LU Resources Manager"). A session is active from the time that 
the resources manager receives SESSION_ACTIVATED or +ACTIVATE_SESSION_RSP to 
the time that the resources manager sends DEACTIVATE_SESSION or receives SES~- 
SION_DEACTIVATED. ACTIVE_* COUNT includes sessions that are pending termi- 
nation (see below). ACTIVE_SESSION_COUNT is the Sum of 
ACTIVE _CONWINNERS_ COUNT and ACTIVE _CONLOSERS COUNT. 


6. PENDING * COUNT counts pending-active sessions. These counts are maintained 
by RM ("Chapter 3. LU Resources Manager"). A session is pending active from 
the time that the resources manager sends ACTIVATE_SESSION to the time that 
the resources manager receives ACTIVATE_SESSION_RSP. PENDING_SESSION_COUNT is 
the sum of PENDING CONWINNERS COUNT and PENDING _CONLOSERS COUNT. 


MODE 


Shared Data 


NAME: mode name (see Note 3). 

SESSION_LIMIT: maximuta number of sessions allowed for this partner (LU, mode) pair 

MIN_CONWINNERS LIMIT: minimum number of contention winner sessions 

MIN_CONLOSERS_LIMIT: wminimum number of contention loser sessions 

CNOS_NEGOTIATION_IN_PROGRESS: possible values: TRUE, FALSE 

LIMIT_BEING NEGOTIATED: when CNOS negotiation is in progress, this is the tentative 
new session limit 


ACTIVE_SESSION_COUNT (see Note 5) 
ACTIVE_CONWINNERS_COUNT 
ACTIVE_CONLOSERS_ COUNT 


PENDING_SESSION_COUNT (see Note 6) 


PENDING_CONWINNERS_COUNT 
PENDING _CONLOSERS_ COUNT 
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MODE 


DRAIN_SELF: possible values: YES, NO 
DRAIN_PARTNER: possible values: YES, NO 
AUTO_ACTIVATIONS_LIMIT 


Data Unique to LU Resources Manager 


TERMINATION_COUNT (see Note 4) 
PENDING TERMINATION _CONWINNERS 
PENDING_TERMINATION_CONLOSERS 
SINGLE_SESSION_POLARITY: possible values: FIRST_SPEAKER, BIDDER 


TRANSACTION_PROGRAM 


Each LUCB contains a TRANSACTION_PROGRAM_LIST. This list contains one entry for each 
transaction program Known at the LU. Each TRANSACTION_PROGRAM entry in the TRANS- 
ACTION_PROGRAM_LIST contains information describing one transaction program. | 


The TRANSACTION _PROGRAM_LIST is created at system-definition time . The initial values of 
the fields in each TRANSACTION_PROGRAM entry are implementation-defined. 


_ NOTE: Transaction program names consist of type-AE up through type-SR symbol 
strings, depending upon the implementation. See "Appendix E. Request/Response 
Unit (RU) Formats" for symbol-string definitions. 


TRANSACTION_PROGRAM 


Shared Data 


TRANSACTION_PROGRAM_NAME (up to 64 bytes long) 

PRIVILEGED_FUNCTIONS_ LIST: possible values: ATTACH_SERVICE_TP, CHANGE_NUMBER_OF_SESSIONS, 
DEFINE LU_PARAMETERS, DISPLAY_LU_PARAMETERS, SESSION_CONTROL 

RESOURCES SUPPORTED_LIST: possible values: BASIC_CONVERSATION, MAPPED_CONVERSATIN 


Data Unique to PS.INITIALIZE 


NUMBER_OF_PIP_SUBFIELDS 


Data Unique to RM 


SYNC_LEVELS_SUPPORTED_LIST: possible values: NONE, CONFIRM, SYNCPT 


Data Unique to PS.MC 


MC_FUNCTIONS_SUPPORTED_LIST: possible values: MAPPING, FMH_DATA 
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LULU_CB 


LULU_CB 


The LU-LU session control block is used by LU network services (LNS) to Keep information 
about an LU-LU session. There is one LULU_CB for each LU-LU session. 


LULU_CB 


The following fields are always set to the correct value when the 
LULU_CB is created and initialized (independent of what caused it to 


be created). 


CP_LU: contains information pertaining to CP_LU session 
CP_ID: control point identifier (see page A-2) 
HS_ID: identifier for CP-LU half-session 
LUNAME: contains local and fully qualified target LU names 
MODENAME: mode name for this LU-LU session 
SESSION_ID: session instance identifier 
SESSION_INFORMATION 
HALF_SESSION_TYPE: possible values: PRI, SEC 
SESSION_TYPE: possible values: FIRST_SPEAKER, BIDDER 


CORRELATOR field is set when an ACTIVATE_SESSION (from RM) causes the 


creation of the LULU_CB. It is used by RM to correlate ACTI- 
VATE_SESSION_RSP to ACTIVATE_SESSION. 


CORRELATOR 
LU_LU: information pertaining to the LU-LU session 


PC_ID—path control identifier representing the path control process 
being used by this LU-LU session. This field is set when a_ BIND 
request or PC_CONNECT_RSP is received. 


PC_ID 


ALS—adjacent link station identifier representing the link this LU-LU 
session is using. This field is set when a BIND request is received 
or a PC_CONNECT is sent. It is used only in peripheral nodes. 


ALS 


ADDRESS—the addresses of the LUs for this LU-LU session. For subarea 
nodes this field is set when a CINIT or BIND request is received. For 


peripheral nodes it is set when a BIND request or PC_CONNECT_RSP is 
received. 


ADDRESS (see page A-34) 
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LULU_CB 


HS _ID—this field contains the process identifier for the LU-LU 
half-session process (HS). When the half-session process does not 
exist, this field is set to a null value. 


HS_ID 


SENT_INITIATE_RQ fields are set when an INIT-SELF request is sent. — 


SENT_INITIATE_RQ — 
URC: used to correlate future CINIT or BIND request. 
SNF: TH sequence number of sent INIT-SELF request (used to correlate 
INIT-SELF response). 


SENT_BIND_RQ fields are set when a BIND request is sent. A copy of 
the sent BIND request RU is saved because it is needed to perform 
error checking on the received BIND response. 


SENT_BIND_RQ 
SNF: TH sequence number of sent BIND request (used to correlate BIND resonse) 
BIND_RQ_RU: saved BIND request RU 


SENT_UNBIND_RQ fields are set when an UNBIND request is sent. 


SENT_UNBIND_RQ 


SNF: TH sequence number of sent UNBIND request (used to correlate UNBIND response) 


RANDOM holds the random data sent to a partner LU in BIND or BIND 
response, and the random data received in a BIND response. 


RANDOM 
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RCB 


RCB 


The RCB_LIST contains information about resources. There is one RCB_LIST per LU and one 
RCB per resource Known by that LU. The RCB_LIST is managed by RM ("Chapter 3. LU 
Resources Manager''). Entries are added to, and deleted from, the RCB_LIST by the 
resources manager. The RCB_LIST is also referenced by presentation services, e.g.» 
PS.CONV ("Chapter 5.1. Presentation Services--Conversation Verbs"). The RCB_LIST contains 
entries for all the resources associated with all the transaction program instances active 
at a particular LU. 


NOTES: 1. The (partner) LULNAME is the name that a transaction program specifies in con- 
junction with the MODE _NAME when requesting the allocation of a conversation. 
It is a local name by which one LU Knows another LU and is not sent outside 
the LU. The maximum length of the LULNAME is implementation-defined, but is 
shown here as having a maximum length of 17 characters. 


2. LU names consist of type-G symbol strings. Mode names consist of type A symbol 
strings. Conversation correlators consist of type-G symbol strings. See "Ap- 
pendix E. Request/Response Unit (RU) Formats" for symbol string definitions. 


3. When the resources manager receives a GET_SESSION (page A~-26) from PS.CONV and 
determines that only a bidder half-session is available (i.e., all first 
speaker half-sessions are in use), it has to request permission to use the 
half-session. Because permission may be denied, SESSION _PARMS_PTR- points to 
the GET_SESSION record while the request for permission to use the session 1s 
outstanding. If permission is denied, the GET_SESSION record is used to issue 
a new request for a session. After permission has been granted, or if a first 
speaker session can be allocated, SESSION_PARMS_PTR has a value of NULL. 


RCB 


Shared Data 


RCB_ID: ID of this RCB 

TCB_ID: ID of the transaction that owns this RCB 

HS ID: ID of the half-session associated with this RCB 

LU_NAME: Partner LU name (see Notes I and 2) 

MODE_NAME (see Note 2) 

CONVERSATION_CORRELATOR (see Note 2) 

CONVERSATION_TYPE: possible values: BASIC_CONVERSATION, MAPPED_CONVERSATION 
FSM_CONVERSATION page 5.1-63 


Data Unique to RM 


SESSION_PARMS_PTR (see Note 3) 
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RCB 


Data Unique to PS.CONV 


PS_TO_HS_RECORD, see SEND _DATA_RECORD : page A~-24 
SEND_LL_REMAINDER: number of bytes remaining to be sent in the outgoing 
logical record 
RECEIVE _LL_REMAINDER: number of bytes remaining to be received in the incoming 
logical record | | . | 
POST_CONDITIONS 
FILL: possible values: BUFFER, LL 
MAX_LENGTH: maximum number of bytes in incoming logical record or buffer 
LOCKS: possible values: SHORT, LONG Ce 
SEND_LL_BYTE: possible values: PRESENT, NOT_PRESENT 
SAVED_BYTE: retains SENDO_LL_BYTE (reserved when SEND_LL_BYTE=NOT_PRESENT ) 
MAX_BUFFER_LENGTH: maximum number of bytes in outgoing logical record or buffer 
SYNC_LEVEL: possible values: NONE, CONFIRM, SYNCPT 
SECURITY_SELECT: possible values: NONE, SAME, PGM 
RQ_TO_SEND_RCVD: possible values: YES, NO 
FSM_ERROR_OR_ FAILURE page 5.1-65 
FSM_POST page 5.1-66 
HS TO_PS_BUFFER_LIST: List of BUFFER_ELEMENT (see page A-8) 


Data Unique to PS.MC 


MC_RECEIVE_BUFFER: Contains RECEIVED_INFO (see page A-8) 
MAPPER_SAVE_AREA 
MC_MAX_SEND_SIZE: maximum number of bytes in a mapped-conversation logical record 


BUFFER ELEMENT © 


BUFFER_ELEMENT is the structure that is inserted into the HS_TO_PS BUFFER_LIST. The 


HS_TO_PS_BUFFER_LIST is contained within an RCB and consists of information received by 
| PS.CONV ("Chapter 5.1. Presentation Services--Conversation Verbs") from the half-session 
| but not yet passed to the transaction program. 


BUFFER_ELEMENT: 
TYPE: possible values: DATA, FMH7, CONFIRM, PREPARE_TO_RCV_FLUSH, 
PREPARE _TO_RCV_CONFIRM, DEALLOCATE_FLUSH, DEALLOCATE_CONFIRM 
DATA (reserved when TYPEZDATA, FMH7) 


RECEZVED_INFO 


RECEIVED_INFO is the structure that is inserted into the MC_RECEIVE_BUFFER_LIST. The 
MC_RECEIVE_BUFFER_LIST is contained within an RCB and consists of information received by 
PS.MC ("Chapter 5.2. Presentation Services--Mapped Conversation Verbs") but not yet passed 
to the transaction program. 


RECEIVED_INFO 
TYPE: possible values: MAP_NAME, MAP_NAME_AND DATA_CONTINUED, 
DATA_CONTINUED, MAPPED_DATA, INDICATOR, RC 
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ScB 


SCB 


There is one SCB per half-session. SCBs are maintained by the resources manager. 


NOTES: 1. The (partner) LU_LNAME is the name that a transaction program specifies in con- 
junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one LU knows another LU and is not sent outside 
the LU. The maximum length of the LULNAME is implementation-defined, but is 
shown here as having a maximum length of 17 characters. 


LU names consist of type-6 symbol strings. Fully-qualified LU names and mode 
names consist of type-A symbol strings. See “Appendix E&. Request/Response 
Unit (RU) Formats" for symbol-string definitions. 


SCB 


HS_ID: unique SCB identifier 

LU_NAME: partner LU name (see Notes) 

MODE_NAME: mode name (see Note 2) 

RCB_ID: ID of RCB representing the conversation that is using this session; 
null if no conversation is using this session 

FULLY_QUALIFIED_LU_NAME: Partner LU name (see Note 2) 


Data Unique to RM 


RANDOM DATA: used to validate FMH~-12 
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TCcSB 


TCB 


The TCB_LIST contains information about active transaction program instances. There is 
one TCB_LIST per LU and one TCB per active transaction program instance running at that 
LU. The TCB_LIST is managed by RM ("Chapter 3. LU Resources Manager"). Entries are added 
to and deleted from the TCB_LIST by the resources manager. The TCB_LIST is also refer- 


enced by presentation services, @.g., PS.CONV ("Chapter 5.1. Presentation Serv- 
ices--Conversation Verbs"). 


Each TCB contains an embedded RESOURCES LIST, which contains one (pointer) entry for each 


resource associated with a particular transaction program instance. 


NOTES: 1. Transaction program names and Access Security Information subfield consist of 
type-AE up through type-GR symbol strings, depending upon the implementation. 


2. Each entry in the RESOURCES _LIST has a corresponding entry in the RCB_LIST. 
The RCB_LIST contains entries for all the resources associated with all the 
transaction program instances running at the LU. In contrast, the 
RESOURCES_LIST contains entries for only those resources associated with a 
particular transaction program instance. 


TCB 


TCB_ID: identifies the PS process 
TRANSACTION _PROGRAM_NAME (See Note 1) 
OWN _LU_ID 
LUW_IDENTIFIER 
FULLY_QUALIFIED_LU_NAME 
LUW_INSTANCE 
LUW_SEQUENCE_NUMBER 
RESOURCES LIST (see Note 2) 
CONTROLLING_COMPONENT: possible values: TP, SERVICE_COMPONENT 
INITIATING SECURITY: initiating security information is received 
on the Attach that started this TP; (see Note 1) 
PROFILE 
USERID 


HS_TO_LNS_RECORD 


HS_TO_LNS_RECORD is a record sent by the half-session (HS) to LU network services (LNS). 


HS_TO_LUNS_ RECORD: contains INIT_HS_RSP, HS_RCV_RECORD, or ABORT_HS record (see below) 
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ABORT_HS 


ABORT_HS 


ABORT_HS indicates to LU network services that the half-session has found a severe error 


and cannot continue processing. This will cause an UNBIND request to be sent for the 
aborted half-session. 


NOTE: This record is sent only by LU-LU half-sessions. 


ABORT_HS 
HS_ID: identifies the half-session sending this record 
SENSE_CODE: indicates the reason the half-session aborted 


HS_RCV_RECORD 


This record contains PIU information pertaining to FMO NS RUs that flow from the control 
point to the LU on the LU-CP session (e.g., CINIT, NOTIFY). 


NOTE : This record is sent only by LU-CP half-sessions. 


HS_RCV_RECORD 
HS_ID: identifies the half-session sending this record 
PIU (see page A-35) | 


INIT_HS_RSP 


This record is a response to the INIT_HS record that was sent from LU network services 


(LNS) to the half-session (HS) to initialize the half-session. The response indicates 
whether or not the initialization was successful (POS) or not (NEG). When NEG, the reason 
is indicated by the sense data in SENSE_CODE. 


INIT_HS_RSP 
TYPE: possible values: POS, NEG 
SENSE_CODE: indicating the type of error (reserved when TYPE=P0S) 
HS_ID;: identifies the half-session sending the record 


HS_TO_PC_RECORD 


HS _TO_PC_RECORD is a record sent by the half-session (HS) to path control (PC). It con- 
tains the sending half-session's process identifier (many half-sessions may send to the 
same path control) and PIU information from which path control will build and send a PIU. 


HS_TO_PC_RECORD 
HS_ID: identifier of the half-session sending this record. 
PIU: contains path information unit (see page A-35) 
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HS_TO_PS_RECORD 


HS_TO_PS_RECORD 


The HS_TO_PS_RECORD is the record that HS ("Chapter 6.0. Half-Session'") sends to PS_CONV 
("Chapter 5.1. Presentation Services--Conversation Verbs"). 7 


HS_TO_PS_RECORD: contains a RECEIVE_DATA, REQUEST_TO_SEND, 
RSP_TO_REQUEST_TO_SEND, RECEIVE_ERROR, or CONFIRMED record (see below) 


CONFIRMED 


CONFIRMED is sent by the half-session to PS_CONV to inform PS_CONV that a_ positive 
response to the previous request for confirmation has been received. Confirmation is 
requested when SEND_PARM.TYPE (page A-36) = CONFIRM, DEALLOCATE_CONFIRM, PRE- 
PARE_TO_RCV_CONFIRM_SHORT, or PREPARE_TO_RCV_CONFIRM_LONG. 


CONFIRMED 
HS_ID: identifies the half-session sending this record 


RECEIVE_DATA 


RECEIVE_DATA is sent by the half-session to PS_CONV to inform PS_CONV of receipt of con- 
versation data. The data is passed to PS_CONV in the DATA field. If FMH = YES, the DATA 
contains an FMH-7. 


RECEIVE_DATA | 
HS ID: identifies the half-session sending this record 
FNH: possible values: YES, NO (If FMH=YES, DATA contains an FMH-7. ) 
TYPE: possible values: NOT_END_OF_DATA, CONFIRM, PREPARE_TO_RCV_CONFIRM, 
PREPARE_TO_RCV_FLUSH, DEALLOCATE_CONFIRM, DEALLOCATE_FLUSH 
DATA: data received from partner transaction program 


| | | | RECEIVE _ERROR 


RECEIVE_ERROR 1s sent by the half-session to PS_CONV to inform PS_CONV that a -RSP(0846) 
has been received. 


RECEIVE ERROR 
HS_ID: identifies the half-session sending this record 
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REQUEST_TO_SEND 


REQUEST_TO_SEND 


REQUEST_TO_SEND is sent by the half-session to PS_CONV to inform PS_CONV that the trans- 


action program at the partner LU has requested to enter the send state for the conversa- 
tion. 


REQUEST_TO_SEND 
HS ID: identifies the half-session sending this record 


RSP_TO_REQUEST_TO_SEND 


RSP_TO_REQUEST_TO_SEND is sent by the half-session to PS_CONV to inform PS_CONV that the 
response to the previous REQUEST_TO_SEND record (page A-26) has been received. 


RSP_TO_REQUEST_TO_SEND | 
HS_ID: identifies the half-session sending this record 


HS_TO_RM_RECORD 


The HS_TO_RM_RECORD is the record that HS ("Chapter 6.0. Half-Session") sends to RM 
("Chapter 3. LU Resources Manager"). 


HS_TO_RM_RECORD: contains ATTACH_HEADER, BID, BID_RSP, FREE SESSION, 
BIS_RQ, BIS_REPLY, RTR_RQ, RTR_RSP, or SECURITY_HEADER record (see below) 


ATTACH_HEADER 


ATTACH_HEADER is sent by the half-session to the resources manager to inform the resources 
manager of the receipt of an FMH-5 on the half-session. The HEADER field contains the 
FMH-5. 


ATTACH_HEADER | 
HS_ ID: identifies the half-session sending this record 
HEADER: contains the received FMH-5 
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BID 


BID 


BID is sent by the half-session to the resources manager to inform the resources manager 


that the partner LU has requested permission to use the half-session for a conversation. 
The resources manager will reply with a BID_RSP record (page A-28). The half-session will 
send a BID record to the resources manager even if the partner LU is the first-speaker. 


BID 
HS_ ID: identifies the half-session sending this record 


BID_RSP 


BID_RSP is sent by the half-session to the resources manager to inform the resources man- 
ager of the partner LU's response to the local LU's request to use the session (see 
BID_WITHOUT_ATTACH [page A-29] and BID_WITH_ATTACH [page A-28]). BID_RSP is. sent by the 
half-session only if the local LU is the bidder. If RTI = NEG, SENSE_CODE contains the 
sense data carried on the negative response. 


BID_RSP 
HS_ ID: identifies the half-session sending this record 
RTI: type of response—possible values: POS, NEG 
SENSE_CODE: indicates the type of error (reserved when RTI=P0S) 


BIS_RQ 


BIS_RQ is sent by the half-session to the resources manager to inform the resources manag- 
er that a BIS(RQE1) request unit was received. 


BIS RQ 
HS ID: identifies the half-session sending this record 


BIS_REPLY 


BIS_REPLY is sent by the half-session to the resources manager to inform the resources 
manager that a BIS(RQE3) request unit was received. 


BIS REPLY 
HS_ID: identifies the half-session sending this record 
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FREE_SESSION 


FREE_SESSION 


FREE_SESSION is sent by the half-session to the resources manager to inform the resources 
manager that the half-session has become free (1.e., not in use by a conversation). 


FREE_SESSION 
HS_ID: identifies the half-session sending this 
record (the half-session that has become free) 


RTR_RQ 


RTR_RQ is sent by the half-session to the resources manager to inform the resources manag- 
er that an RTR request unit was received. 


RTR_RQ 
HS_ID: identifies the half-session sending this record 


RTR_RSP 


RTR_RSP is sent by the half-session to the resources manager to inform the resources man- 
ager that an RTR response unit was received. If RTI = NEG, SENSE_CODE contains the sense 
data carried on the negative response. 


RTR_RSP 
HS ID: identifies the half-session sending this record 
RTI type of response: possible values: POS, NEG 
SENSE_CODE: indicates the type of error (reserved when RTI=POS) 


SECURITY_HEADER 


SECURITY_HEADER is sent by the half-session to the resources manager to inform the 
resources manager of the receipt of an FMH-12 on the half-session. The HEADER field con- 
tains the FMH-12. 


SECURITY_HEADER 
HS ID: identifies the half-session sending this record 
HEADER: contains the received FMH-12 
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LNS_TO_HS_RECORD 


_LNS_TO_HS_RECORD 


LNS_TO_HS_RECORD is a record sent by LU network services (LNS) to the half-session (HS). 


LNS_TO_HS_ RECORD: contains HS_SEND_RECORD or INIT_HS record (see below) 


HS_SEND_RECORD 


This record contains PIU information pertaining to FMD NS RUs that flow from the LU to the 
control point on the LU-CP session (e.g., INIT-SELF, SESSST). 


NOTE: This record is sent only to LU-CP half-sessions. 


HS_SEND_RECORD 
PIU (see page A-35) 


INIT_HS 


This record contains the information necessary for the half-session to initialize itself. 


It is sent when a successful session activation occurs and contains information from the 
activation RUs (e.g., BIND, ACTLU). This is the first record received by the half-session 
after its creation. 


INIT_HS 
PC_ID: identifies the path control the half-session communicates with 
TYPE of half-session: possible values: PRI, SEC 
DATA_TYPE: specifies whether the DATA contains ACTLU image or BIND image 
DATA: contains either ACTLU image or BIND image 
ACTLU_IMAGE: contains fields associated with activating an LU-CP half-session 
FM_PROFILE (see ACTLU in Appendix E) 
TS PROFILE (see ACTLU in Appendix E) 
MAX_RU_SIZE: maximum RU size to be used on the LU-CP session 
BIND_IMAGE: fields associated with activating an LU-LU half-session 
(see BIND request in Appendix E) 


LNS_TO_NNM_RECORD 


LNS_TO_NNM_RECORD is a record sent by LU network services (LNS) to the nodal NAU manager 
(NNM). 


LNS_TO_NNM_RECORD: contains BIND_R@Q_SEND_RECORD, BIND_RSP_SEND_RECORD, 
UNBIND_RQ_ SEND _RECORD, UNBIND_RSP_SEND_RECORD, ACTLU_RSP_SEND_RECORD, 
DACTLU_RSP_SEND_RECORD, PC_CONNECT, HIERARCHICAL_RESET_RSP, 
or PC_HS_ CONNECT record (see below) 
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ACTLU_RSP_SEND_RECORD 


ACTLU_RSP_SEND_RECORD 


This record contains information for an ACTLU response PIU that is to be sent. 


ACTLU_RSP_SEND_RECORD 
LU_ID: process identifier of the sending LU 
PC_ID: process identifier of path control to be sent to 
ADDRESS: contains TH address fields (see page A-34) 
PIU: contains ACTLU response (see page A-35) 


BINOD_RQ_SEND_RECORD 


This record contains information for a BIND request PIU that 1s to be sent. 


BIND_RQ_SEND_RECORD 
LU_ID: process identifier of the sending LU 
PC_ID: process identifier of path control to be sent to 
ADDRESS: contains TH address fields (see page A-34) 
PIU: contains BIND request (see page A-35) 


BIND_RSP_SEND_RECORD 


This record contains information for a BIND response PIU that is to be sent. 


BIND_RSP_SEND_RECORD 
LU_LID: process identifier of the sending LU 
PC_ID: process identifier of path control to be sent to 
ADDRESS: contains TH address fields (see page A-34) 
PIU: contains BIND response (see page A-35) 


DACTLU_RSP_SEND_RECORD 


This record contains information for a DACTLU response PIU that is to be sent. 


DACTLU_RSP_SEND_RECORD 
LULID: process identifier of the sending LU 
PC_ID: process identifier of path control to be sent to 
ADDRESS: contains TH address fields (see page A-34) 
PIU: contains DACTLU response (see page A-35) 
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HIERARCHICAL_RESET_RSP 


HIERARCHICAL_RESET_RSP 


This record is a response to a HIERARCHICAL_RESET record. It indicates that hierarchical 
reset processing is complete. 


HIERARCHICAL_RESET_RSP 
LU_ID: process identifier of the sending LU 
PC_ID: process identifier of path control to be sent to 
CP_ID: control point identifier (see page A-2) 


PC_CONNECT 


This record is used, by primary LUs, to request information about a path control that will 
be used to activate an LU-LU session. For peripheral nodes, the adjacent link station 
(ALS) 1s used to specify the path to be used. For subarea nodes, the subarea address for 
the secondary LU (SUBAREA_ADDRESS) and path information (PATH_INFORMATION) are used to 


specify the path. Path information includes the class-of-service name and the virtual 
ruute identifier list. 


PC_CONNECT 
LU_ID: process identifier of the sending LU 
HS_ID: half-session process identifier used to correlate the PC_CONNECT_RSP 


TYPE of node this PLU resides in: possible values: PERIPHERAL, SUBAREA 
ALS: adjacent link station (reserved when TYPE=SUBAREA) 


SUBAREA_ADDRESS: for SLU needed to assign route (reserved when TYPE=PERIPHERAL ) 
PATH_INFORMATION: contains class-of-service and virtual-route-identifier list 
(reserved when TYPE=PERIPHERAL ) 


PC_HS_CONNECT 


This record is used to notify a path control that it can now send to, and receive from, a 
newly activated half-session. 


PC_HS_CONNECT 
LU_LID: process identifier of the sending LU | 
PC_ID: process identifier of path control to be sent t 
HS_ID: half~-session process identifier 
ADDRESS: contains TH address fields (see page A-34) 
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PC_HS_DISCONNECT 


PC_HS_DISCONNECT 


This record is used to notify a path control that a half-session has been deactivated. 
Path control will stop sending to, and receiving from, the half-session. 


PC_HS_DISCONNECT 
LU_ID: process identifier of the sending LU 
HS ID: process identifier of half-session being deactivated 


UNBIND_RQ_SEND_RECORD 


This record contains information for an UNBIND request PIU that is to be sent. 


UNBIND_RQ_SEND_RECORD 
LU_ID: process identifier of the sending LU 
PC_ID: process identifier of path control to be sent to 
ADDRESS: contains TH address fields (see page A-34) 
PIU: contains UNBIND request (see page A-35) 


UNBIND_RSP_SEND_RECORD 


This record contains information for an UNBIND response PIU that is to be sent. 


UNBIND_RSP_SEND_RECORD 
LU_ID: process identifier of the sending LU 
PC_ID: process identifier of path control to be sent to 
ADDRESS: contains TH address fields (see page A-34) 
PIU: contains UNBIND response (see page A-35) 


LNS_TO_RM_RECORD 


The LNS_TO_RM_RECORD is the record that LNS ("Chapter 4. LU Network Services") sends to RM 
("Chapter 3. LU Resources Manager"). 


LNS_TO_RM_RECORD: contains ACTIVATE_SESSION_RSP, SESSION_ACTIVATED, 
SESSION_DEACTIVATED, or CTERM_DEACTIVATE_SESSION record (see below) 
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ACTIVATE_SESSION_RSP 


| ACTIVATE _SESSION_RSP 


ACTIVATE_SESSION_RSP is sent by LU network services to the resources. manager in reply to 
an ACTIVATE_SESSION record (page A-31). ACTIVATE_SESSION_RSP records need not be sent in 
the same order as the the ACTIVATE_SESSION records, so CORRELATOR is used to correlate the 
ACTIVATE_SESSION_RSP to the ACTIVATE_SESSION. If TYPE = POS (a session was activated), 
SESSION_INFORMATION contains session characteristics. If TYPE = NEG (a session was not 
activated), ERROR_TYPE contains a retry/no-retry indication. 


ACTIVATE_SESSION_RSP 
CORRELATOR: as supplied in ACTIVATE_SESSION (see page A-31) 
TYPE of response: possible values: POS, NEG 
SESSION_INFORMATION (reserved when TYPE=NEG—see page A-36) 
ERROR_TYPE: possible values: RETRY, NO_RETRY (reserved when TYPE=P0S) 


CTERM_DEACTIVATE_SESSION 


CTERM_DEACTIVATE_SESSION is sent by LU network services to the resources manager to 
request normal shutdown (i.e., BIS exchange followed by DEACTIVATE_ SESSION) of the session 
identified by HS_ID. | 


CTERM_DEACTIVATE_SESSION 
HS ID: identifier of the half-session to be shut down 


SESSION_ACTIVATED 


SESSION_ACTIVATED is sent by LU network services to the resources manager to notify the 
resources manager that the partner LU named by LU_NAME and MODE_NAME has activated a ses- 
sion to this LU. The characteristics of the session are given in SESSION_INFORMATION. 


NOTES: 1. The (partner) LU_LNAME is the name that a transaction program specifies in con- 
junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one LU Knows another LU and is not sent outside 
the LU. The maximum length of the LU_NAME is implementation-defined. 


LU names consist of type-G symbol strings. Mode names consist of type-A sym- 
bol strings. See "Appendix E. Request/Response Unit (RU) Formats” for 
- symbol-string definitions. | 


SESSION_ACTIVATED 
SESSION_INFORMATION (see page A-36) 
LU_NAME (see Notes 1 and 2) 
MODE_NAME (see Note 2) 
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SESSION_DEACTIVATED 


SESSION_DEACTIVATED 


SESSION_DEACTIVATED is sent by LU network services to the resources manager to notify the 
resources manager that the session identified by HS_ID has been deactivated by the partner 
LU. 


SESSION DEACTIVATED 
HS ID: identifies half-session that was deactivated 
REASON for deactivation: possible values: NORMAL, ABNORMAL_RETRY, ABNORMAL_NO_RETRY 


NNM_TO_LNS_ RECORD 


NNM_TO_LNS_RECORD is a record sent by the nodal NAU manager (NNM) to LU network services 
(LNS). 


NNM_TO_LNS_ RECORD: contains BIND_RQ_RCV_RECORD, BIND_RSP_RCV_RECORD, 
UNBIND_RQ_RCV_RECORD, UNBIND_RSP_RCV_RECORD, ACTLU_RQ_RCV_RECORD, 
DACTLU_RQ_RCV_RECORD, PC_CONNECT_RSP, SESSION _ROUTE_INOP, or 
HIERARCHICAL_RESET record (see below) 


ACTLU_RQ_RCV_RECORD 


This record contains information about a received ACTLU request PIU. 


ACTLU_RQ_RCV_RECORD 
PC_ID: process identifier of path control that received this PIU 
ADDRESS: contains TH address fields (see page A-34) 
CP_ID: control point identifier (see page A-2) 
PIU: contains ACTLU request (see page A-35) 


BIND_RQ_RCV_RECORD 


This record contains information about a Geceiwes BIND request PIU and information about 
the path control that received it. 


BIND_RQ_RCV_RECORD 
PC_ID: process identifier of path control that received this PIU 
ADDRESS: contains TH address fields (see page A-34) 
PC_ CHARACTERISTICS: path control characteristics (see page A-35) 
PIU: contains BIND request (see page A-35) 
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BIND_RSP_RCV_RECORD 


BIND_RSP_RCV_RECORD 


This record contains information about a received BIND response PIU. 


BIND_RSP_RCV_RECORD 
PC_ID: process identifier of path control that received this PIU 
ADDRESS: contains TH address fields (see page A-34) 
PIU: contains BIND response (see page A-35) 


DACTLU_RQ_RCV_RECORD 


This record contains information about a received DACTLU request PIU. 


DACTLU_RQ_ RCV_RECORD 
PC_ID: process identifier of path control that received this PIU 
ADDRESS: contains TH address fields (see page A-34) 
CP_ID: control point identifier (see page A-2) 
PIU: contains DACTLU request (see page A-35) 


HIERARCHICAL RESET 


This record is used to reset all sessions with respect to a specific control point (e.g.; 
SSCP) session. It contains the identifier of the control point affected (CP_ID) and path 
control process identifier associated with that control point (PC_ID). 


HIERARCHICAL RESET 
PC_ID: path control process identifier associated with the CP-LU session 
CP_ID: control point identifier (see page A-2) 


PC_CONNECT_RSP 


This record is a response to a PC_CONNECT record sent by LU network services (LNS). If 


positive, it contains information about the path control (PC_ID and PC_CHARACTERISTICS) 
that will be used for the LU-LU session being activated. For peripheral nodes, it also 
contains an assigned address (ADDRESS) for the LU-LU session. 


PC_CONNECT_RSP 
HS_ID: half-session process identifier used to correlate to PC_CONNECT record 
TYPE of response: possible values: POS, NEG 
PC_ID: process identifier of path control that received this PIU 
(reserved when TYPE=NEG) 
ADDRESS: contains TH address fields (for peripheral node—see page A-34) 
PC_CHARACTERISTICS: path control characteristics (reserved when TYPE=NEG—see page A-35) 
SENSE_CODE: indicating the type of error (reserved when TYPE=P0S) 
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SESSION_ROUTE_INOP 


SESSION_ROUTE_INOP 


This record indicates that a route, represented by a path control process, has become 
inoperative. 


SESSION_ROUTE_INOP 
PC_ID: process identifier of path control process that has become inoperative 


UNBIND_RQ_RCV_RECORD 


This record contains information about a received UNBIND request PIU. 


UNBIND_RQ RCV_RECORD 
PC_ID: process identifier of path control that received this PIU 
ADDRESS: contains TH address fields (see page A-34) 
PIU: contains UNBIND request (see page A-35) 


UNBIND_RSP_RCV_RECORD 


This record contains information about a received UNBIND response PIU. 
UNBIND_RSP_RCV_RECORD 
PC_ID: process identifier of path control that received this PIU 


ADDRESS: contains TH address fields (see page A-34) 
PIU: contains UNBIND response (see page A-35) 


PC_TO_HS_RECORD 


PC_TO_HS_RECORD is a record sent by path control (PC) to the half-session (HS). It con- 
tains PIU tnformation that path control obtained from a received PIU. 


PC_TO_HS_RECORD 
PIU (see page A-35) 
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PS_TO_HS_RECORD 


PS_TO_HS_RECORD 


The PS_TO_HS_RECORD is the record that PS_CONV ("Chapter 5.1. Presentation 
ices--Conversation Verbs") sends to HS ("Chapter 6.0. Half-Session'). . 


PS _TO_HS_RECORD: contains SEND_DATA_RECORD, SEND_ERROR, REQUEST_TO_SEND; 
or CONFIRMED record (see below) 


| CONFIRMED 


CONFIRMED is sent by PS_CONV to the half-session to request the half-session to send a 
positive response to a previous request for confirmation by the partner transaction pro- 
gram. 


CONFIRMED 


REQUEST_TO_SEND 


REQUEST_TO_SEND is sent by PS_CONV to the half-session to request the half-session to send 


a SIGNAL(SOFT). SIGNAL(SOFT) is used to request permission to enter the send state for 
the conversation. 


REQUEST_TO_SEND 


SEND_DATA_RECORD 


SEND_DATA is sent by PS_CONV to the half-session to request the half-session to send con- 
versation data. 


SEND_DATA_RECORD 
SEND_PARM: (see page A~-36) 


SEND_ERROR 


SEND_ERROR is sent by PS_CONV to the half-session to request the half-session to send a 
~RSP(0846). 


SEND_ERROR 
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PS _TO_RM_RECORD 


P5_TO_RM_RECORD 


The PS_TO_RM_RECORD is the record that presentation services (i.e@., PS.CONV [Chapter 5.1. 
Presentation Services--Conversation Verbs"], PS.INITIALIZE ["Chapter 5.0. Overview of 
Presentation Services"], or PS.COPR ["Chapter 5.4. Presentation Services--Control-Operator 


Verbs"]) sends to RM ("Chapter 3. LU Resources Manager") to request that a certain func- 
tion be per formed. 


PS _TO_RM_RECORD: contains ALLOCATE_RCB, GET_SESSION, DEALLOCATE_RCB, TERMINATE_PS, 
CHANGE SESSIONS, UNBIND_PROTOCOL_ERROR, RM_ACTIVATE_SESSION, or 
RM_DEACTIVATE_SESSION record (see below) 


ALLOCATE_RCB 


ALLOCATE_RCB is sent by PS.CONV to the resources manager to request creation and initial- 
ization of a resource control block. The resources manager will also attempt to reserve a 
first-speaker session if IMMEDIATE_SESSION = YES. The resources manager will reply to the 
ALLOCATE_RCB with an RCB_ALLOCATED record (page A-32). 


NOTES: 1. The (partner) LU_LNAME is the name that a transaction program specifies in con- 
junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one LU Knows another LU and is not sent outside 
the LU. The maximum length of the LU_LNAME is implementation-defined, but is 
shown here as having a maximum length of 17 characters. 


2. LU names consist of type-G symbol strings. Mode names consist of type-A sym- 
bol strings. See "Appendix E. Request/Response Unit (RU) Formats" for 
symbol-string definitions. 


ALLOCATE_RCB 
TCB_ID: ID of PS process that sent ALLOCATE_RCB 
LU_NAME (see Notes 1 and 2) 
MODE_NAME (see Note 2) 
IMMEDIATE_SESSION: possible values: YES, NO 
SYNC_LEVEL: possible values: NONE, CONFIRM, SYNCPT 
SECURITY_SELECT: possible values: NONE, SAME, PGM 
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CHANGE_SESSIONS 


CHANGE_SESSIONS 


CHANGE_SESSIONS is sent by PS.COPR to the resources manager to inform the resources manag- 
er of a change in the session limits for (LU_NAME, MODE_NAME). PS.COPR changes the ses- 
sion limits in the MODE control block (page A-3) before sending this record to the 
resources manager. RESPONSIBLE = YES if this LU is responsible for deactivating sessions 
to satisfy the new session limits. DELTA contains the (signed) difference between the 
current MODE .SESSION_LIMIT and the previous MODE .SESSION_LIMIT. 


NOTES: 1. The (partner) LU_LNAME is the name that a transaction program specifies in con- 
junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one LU knows another LU and is not sent outside 
the LU. The maximum length of the LU_LNAME is implementation-defined. 


2. LU names consist of type-G symbol strings. Mode names consist of type-A sya~ 
bol strings. See "Appendix E. Request/Response Unit (RU) Formats" for symbol 
string definitions. 


CHANGE_SESSIONS 
TCB_ID: ID of the PS process that sent CHANGE_SESSIONS 
RESPONSIBLE: possible values: YES, NO 
LU_NAME (see Notes 1 and 2) 
MODE_NAME (see Note 2) 
DELTA: change in MODE.SESSION_LIMIT 


DEALLOCATE_RCB 


DEALLOCATE_RCB is sent by PS.CONV to the resources manager to request destruction of the 
resource control block identified by RCB_ID. The resources manager will reply to the 
DEALLOCATE_RCB with an RCB_DEALLOCATED record (page A-33). 


DEALLOCATE_RCB 
TCB_ID: ID of the PS process that sent DEALLOCATE_RCB 
RCB_ID: ID of the RCB to deallocate 


GET_SESSION 


GET_SESSION is sent by PS.CONV to the resources manager to request the allocation of a 
session to the conversation identified by RCB_ID. The resources manager will reply to the 
GET_SESSION with a SESSION_ALLOCATED record (page A-33). 


GET_SESSION 
TCB_ID: ID of the PS process that sent GET_SESSION 
RCB_ID: ID of the conversation 
BID_INDICATOR: possible values: ATTACH, NO_ATTACH 
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RM_ACTIVATE_SESSION 


RM_ACTIVATE_SESSION 


RM_ACTIVATE_SESSION is sent by PS.COPR to the resources manager to request activation of a 
new session with the partner LU identified by LU_NAME on wmode name identified by 
MODE_NAME. This record is sent as a result of the ACTIVATE_SESSION control operator verb. 


NOTES: 1. The (partner) LU_LNAME is the name that a transaction program specifies in con- 


junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one LU Knows another LU and is not sent outside 
the LU. The maxima length of the LULNAME is implementation-defined, but is 
shown here as having a maximum length of 17 characters. 


LU names consist of type-6 symbol strings. Mode names consist of type-A synm- 
bol strings. See "Appendix E. Request/Response Unit (RU) Formats" for 
symbol-string definitions. 


RM_ACTIVATE_SESSION 
TCB_ID: ID of the PS process that sent RM_ACTIVATE_SESSION 
LU_NAME (see Notes 1 and 2) 
MODE_NAME (see Note 2) 


RM_DEACTIVATE_SESSION 


RM_DEACTIVATE_SESSION is sent by PS.COPR to the resources manager to request deactivation 


of the session identified by SESSION_ID. This record is sent as a result of the DEACTI- 
VATE_SESSION control-operator verb. 


RM_DEACTIVATE_ SESSION 
TCB_ID: ID of the PS process that sent RM_DEACTIVATE_SESSION 
SESSION_ID: identifies the session 
TYPE: possible values: NORMAL, CLEANUP 


TERMINATE_PS 


TERMINATE_PS is sent by PS_INITIALIZE to the resources manager to request termination of 
the process that comprises presentation services and the transaction program. 


TERMINATE_PS 
TCB_ID: ID of the PS process to be terminated 
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UNBIND_ PROTOCOL_ERROR 


UNBIND_PROTOCOL_ERROR 


UNBIND_PROTOCOL_ERROR is sent by PS_CONV or PS_INITIALIZE to the resources manager to 


request abnormal termination of the session identified by HS_ID. The record is sent when 
the partner LU commits a serious protocol error. The sense data to be carried on the 
UNBIND is in SENSE_CODE. 


UNBIND_PROTOCOL_ERROR 
TCB_ID: ID of the PS process that sent UNBINO_PROTOCOL_ERROR 
HS_ID: ID of the half-session to be deactivated 
SENSE_ CODE 


RM_TO_HS_RECORD 


The RM_TO_HS_RECORD is the record that RM ("Chapter 3. LU Resources Manager") sends to HS 
("Chapter 6.0. Half-Session’). 


RM_TO_HS_RECORD: contains BID_WITHOUT_ATTACH, BID_RSP, BID _WITH_ATTACH, BIS_REPLY, 
HS_PS_CONNECTED, BIS_RQ, YIELD_SESSION, RTR_RQ, RTR_RSP, or ENCIPHERED_RD2 record (see below) 


BID_RSP 


BID_RSP is sent by the resources manager to the half-session in response to a previous BIO 
record (page A~14) from the half-session. If RTI = POS, the partner LU ts granted permis-~- 
sion to use the session. If RTI = NEG, permission is denied and SENSE_CODE contains the 
sense data to be sent on the negative response. 


BID_RSP 
RTI: possible values: POS, NEG 
SENSE_CODE (reserved when RTI=P0S) 


BID_WITH_ATTACH | 


BID_WITH_ATTACH is sent by the resources manager to the half-session to request permission 
(from the partner LU) to use the session. The request for permission is accompanied by 
conversation data (including the FMH-5 that will attach the remote transaction program) in 
the SENO_PARM structure (page A~-36). The resources manager will send BID WITH_ATTACH if 


this LU is the first speaker or the bidder. When bidding for a session, the resources 
manager chooses between BIOLNITHOUT_ATTACH and BID_WITH_ATTACH on the basis of the 
BID_INDICATOR field in the GET_SESSION (page A-26) from PS_CONV. If this LU is the bid- 
der, the half-session will inform the resources manager of the partner LU's response with 
a BID_RSP record (page A-14). 


BID_WITH_ATTACH 
SEND_PARM (see page A-36) 


A-28 SNA Format and Protocol Reference Manual for LU Type 6.2 


BID_WITHOUT_ATTACH 


BID_WITHOUT_ATTACH 


BID_WITHOUT_ATTACH is sent by the resources manager to the half-session to request permis- 
sion (from the partner LU) to use the session. The request for permission is not accompa- 


nied by any other data. The resources manager will send BID_WITHOUT_ATTACH only if this 
LU is the bidder, since it does not need permission from the partner LU to use a 
first-speaker session. The half-session will inform the resources manager of the partner 
LU's response with a BID_RSP record (page A-14). 


BID_WITHOUT_ATTACH 


BIS_REPLY 


BIS_REPLY is sent by the resources manager to the half-session to request the half-session 
to send a BIS(RQE3) request unit. 


BIS_REPLY 


BIS_RQ 


BIS_RQ is sent by the resources manager to the half-session to request the half session to 
send a BIS(RQE1) request unit. 


BIS_RQ 


HS_PS_CONNECTED 


HS PS CONNECTED is sent by the resources manager to the half-session to inform the 
half-session that it has been connected to a presentation services process. This occurs 
as a result of allocation of a session to a conversation. 


HS _PS_ CONNECTED 
PS_ID: ID of presentation services process 
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RTR_RQ | 


RTR_RQ 


RTR_RQ is sent by the resources manager to the half-session to request the half-session to 
send an RTR request unit. | 


RTR_RQ 


RTR_RSP 


RTR_RSP is sent by the resources manager to the half-session to request the half-session 
to send an RTR response unit. If RTI = NEG, SENSE_CODE contains the sense data to be sent 
with the negative response. 


RTR_RSP 
RTI: possible values: POS, NEG 
SENSE_CODE (reserved when RTI=POS) 


ENCIPHERED_RD2 


ENCIPHERED_RD2 is sent by RM to the half-session to request the half-session to send an 
FMH 12. 


ENCIPHERED_RD2 
SEND_PARM: (see page A-36) 


YIELD_SESSION 


YIELD_SESSION is sent by the resources manager to the half-session to end the open bracket 
ina newly activated session. When a session is activated, the session comes up tn the 


"In-brackets" state with the primary LU in control. If the resources manager at the pri- 
mary LU does not have a waiting session-allocation request (see GET_SESSION, page A-26), 
it will send YIELD_SESSION to the half-session; the half-session then reverts to con- 
tention state. 


YIELD_SESSION 
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RM_TO_LNS_RECORD 


RM_TO_LNS_RECORD 


The RM_TO_LNS_RECORD is the record that RM ("Chapter 3. LU Resources Manager") sends to 
LNS ("Chapter 4. LU Network Services"). 


RM_TO_LNS_ RECORD: contains ACTIVATE_SESSION or DEACTIVATE_SESSION record (see below) 


ACTIVATE_SESSION 


ACTIVATE_SESSION is sent by the resources manager to LU network services to request the 
activation of a session of type SESSION_TYPE with the partner LU identified by LU_NAME and 
mode name identified by MODE_NAME. LU network services will reply to ACTIVATE_SESSION 
with an ACTIVATE_SESSION_RSP record (page A-20) that has the same CORRELATOR value as that 
in the ACTIVATE_SESSION. 


NOTES: 1. The (partner) LU_LNANE is the name that a transaction program specifies in con- 
junction with the MODE_NAME when requesting the allocation of a conversation. 
It is a local name by which one LU knows another LU and is not sent outside 
the LU. The maximum length of the LU_LNAME is implementation-defined. 


LU names consist of type-G symbol strings. Mode names consist of type-A sya- 
bol strings. See "Appendix E. Request/Response Unit (RU) Formats" for 
symbol-string definitions. 


ACTIVATE_SESSION 
CORRELATOR 
SESSION_TYPE: possible values: FIRST_SPEAKER, BIDDER 
LU_NAME (see Notes 1 and 2) 
MODE_NAME (see Note 2) 


DEACTIVATE_SESSION 


DEACTIVATE_SESSION is sent by the resources manager to LU network services to request the 


deactivation of a session. If STATUS = ACTIVE, the session is identified by HS_ID. If 
STATUS = PENDING, the session is identified by CORRELATOR, which contains the same value 
used in the ACTIVATE_SESSION request. 


DEACTIVATE_SESSION 
STATUS: possible values: ACTIVE, PENDING 
CORRELATOR (reserved when STATUS=ACTIVE ) 
HS_ID (reserved when STATUS = PENDING) 
TYPE of deactivation: possible values: NORMAL, CLEANUP, ABNORMAL 
(CLEANUP or ABNORMAL imply STATUS=ACTIVE ) 
SENSE_CODE: reason for deactivation (reserved when TYPE*ABNORMAL ) 
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RM_TO_PS_RECORD 


RM_TO_PS_RECORD 


The RM_TO_PS_RECORD is the record that RM ("Chapter 3. LU Resources Manager") sends to 
PS_INITIALIZE ("Chapter 5.0. Overview of Presentation Services") or PS_CONV ("Chapter 5.1. 
Presentation Services--Conversation Verbs''). 


RM_TO_PS_RECORD: contains ATTACH RECEIVED, RCB_DEALLOCATED, RM_SESSION_ACTIVATED, 
or CONVERSATION_FAILURE record (see below). 


ATTACH_RECEIVED 


ATTACH_RECEIVED is sent by the resources manager to PS_INITIALIZE in a newly created PS 
process (created as the result of an Attach FMH-5). TCB_ID is the ID of the transaction 
control block, RCB_IO is the ID of the initial resource control block, and FMH_5 is the 
FMH-5 that initiated the new presentation services process. The resources manager per- 
forms some validity checks on the FMH-5 before passing it to presentation § services. 
SENSE_CODE indicates the result of these checks. | 


ATTACH_RECEIVED 
TCB_ID: ID of transaction control block 
RCB_ID: ID of resource control block 
SENSE_CODE 
FMH_5: Attach FMH-5 header (see Appendix H) 


CONVERSATION _FAILURE 


CONVERSATION_FAILURE is sent by the resources manager to PS_CONV to notify presentation 


services of the failure of the conversation identified by RCB_ID. The REASON field 
assumes only the values SON or PROTOCOL_VIOLATION. 


CONVERSATION_FAILURE 
RCB_ID: ID of failed conversation 
REASON: possible values: SON, PROTOCOL_VIOLATION 


RCB_ALLOCATED 


RCB_ALLOCATED is sent by the resources manager to PS_CONV in reply to an ALLOCATE_RCB 
(page A-25). RETURN_CODE indicates the success of the allocation. If RETURN_CODE = OK, 
RCB_ID contains the ID of the newly created resource control block. 


RCB_ALLOCATED 
RETURN_CODE: possible values: OK, UNSUCCESSFUL, SYNC_LEVEL_NOT_SUPPORTED 
RCB_ID: ID of newly created resource control block (reserved when RETURN_CODE#0K ) 
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RCB_DEALLOCATED 


RCB_DEALLOCATED 


RCB_DEALLOCATED is sent by the resources manager to PS_CONV in reply to a DEALLOCATE_RCB 
record (page A-26). 


RCB_DEALLOCATED 


RM_SESSION_ACTIVATED 


RM_SESSION_ACTIVATED is sent by the resources manager to PS_COPR in reply to an 


RM_ACTIVATE_SESSION record (page A-27). The success or failure of the session activation 
is indicated in the RETURN_CODE field. 


RM_SESSION_ACTIVATED 
RETURN_CODE: possible values: OK, ACTIVATION_FAILURE_NO_RETRY; 
ACTIVATION_FAILURE_RETRY, LU_MODE_SESSION_LINIT_EXCEEDED 


SESSION_ALLOCATED 


SESSION_ALLOCATED is sent by the resources manager to PS_CONV in reply to a GET_SESSION 


record (page A-26). RETURN_CODE indicates the success or failure of the session allo- 
cation. 


SESSION_ALLOCATED 
RETURN_CODE: possible values: OK, UNSUCCESSFUL_RETRY, UNSUCCESSFUL_NO_RETRY, 


CRV_RQ_RU 
RQ_CODE: possible values: X'C0O' (signifying CRV) 
CRYPTO_SEED 
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ADDRESS 


A-34 


ADDRESS 


ADDRESS contains TH addresses. For subarea nodes they are 6-byte network addresses. For 
peripheral nodes, they along with the TH ODAI bit, comprise a 17-bit session identifier. 
The ODAI identifies the node that assigned the session identifier, allowing two communi- 


cating nodes to assign values independently without collision. The relationship between 
session identifier fields and the OAFI and DAFI fields in the TH depends on the direction 
of flow of the RU. If it flows in the direction of the session-activation request, 
OAFI=SIDH and DAFI=SIDL. If the RU flows in the opposite direction, the mapping § is 
reversed. 


ADDRESS 
Subarea address structure: 
THIS_NAU: address of the local NAU (contains 32-bit subarea and 16-bit 
element address) 
OTHER_NAU: address of the partner NAU (contains 32-bit subarea and 16-bit 
element address) 
Peripheral node structure: 
ODAI: origin/destination assignment indicator 
SIDH: 8-bit address representing the local NAU 
SIDL: 8-bit address representing the partner NAU 


BIU 


This record is used only by the half-session (HS) process. It contains information about 
TH, RH» and RU fields. 


BIU: same as PIU (see page A-35) 
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PC_CHARACTERISTICS 


PC_CHARACTERISTICS 


PC_CHARACTERISTICS: path control characteristics 


PATH _CONTROL_TYPE—-PEER means that this path control is being used for 
a PNCP-mediated session; BACKBONE means that this path control is 
being used for an SSCP-mediated session. 


PATH_CONTROL_TYPE: possible values: PEER, BACKBONE 


ALS—adjacent link station address associated with this path control. 


This field is used only by peripheral nodes. 


ALS 


SEGMENTING—path control segmenting capability. This applies to both 
send and receive segnenting. Either both are supported or both are 
not suppor ted. 


SEGMENTING: possible values: SUPPORTED, NOT_SUPPORTED 


MAX_RU_SEGMENT_SIZE—the maximum number of RU bytes that may be sent 
or received by this path control. This value is independent of path 
control's segmenting capability. 


MAX_RU_SEGMENT_SIZE 


PIU 


This record contains selected TH fields, an RH, and an RU. This is the information used 


by components in layers ahove path control dealing with PIUs (e.g., half-session, LU net- 
work services). The PIU data structure does not contain a comlete TH. It contains only 
the TH fields that are needed by the layers above PC. Other TH fields are not visible 
above PC. 


PIU 

TH: fields from the transmission header needed above the PC layer 
EFI expedited-flow indicator: possible values: EXP, NORMAL 
SNF: contains a 16-bit sequence number field 
DCF: data count field—contains length of BIU 

BIU: basic information unit 
RH: request/response header (see Appendix 0D) 
RU: request unit (see Appendix E) 
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SEND_PARM 


SEND_PARM 


SEND_PARM is a substructure that is embedded in SEND_DATA_RECORD (page A-24) and 
BID_WITH_ATTACH (page A-28). It contains the data to be sent to the half-session as well 
as an encoding of the RH bit settings. If ALLOCATE = YES, this data is the first to be 
sent on a conversation. If FMH = YES, DATA begins with an FM header (FMH-5 or FMH-7). 


SEND_PARM 
ALLOCATE: possible values: YES, NO (if ALLOCATE=YES, DATA is first in bracket) 
FMH: possible values: YES, NO (if FMH=YES, DATA begins with FM header) 

TYPE: possible values: NOT_END_OF_DATA, FLUSH, CONFIRM, DEALLOCATE CONFIRM, 
DEALLOCATE_FLUSH, PREPARE_TO_RCV_FLUSH, PREPARE _TO_RCV_CONFIRM_SHORT, 
PREPARE_TO_RCV_CONFIRM_LONG 

DATA: data to be sent on the half-session 


SESSION_INFORMATION 


SESSION_INFORMATION is a substructure that is. embedded in SESSION_ACTIVATED (page A-20) 


and ACTIVATE_SESSION_RSP (page A-20). Sent from LU Network Services to Resources Manager, 
SESSION_INFORMATION contains data about the session that has just been established. 


SESSION_INFORMATION 
HS_ID: half-session identifier 
HALF_SESSION_TYPE: possible values: PRI, SEC 
BRACKET_TYPE: possible values: FIRST_SPEAKER, BIDDER 
RANDOM_DATA: used to validate FMH-12 
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APPENDIX D 


RH FORMATS 


@ 
ee) 


The request/response header (RH) is a 3-byte 
field; it may be a request header or a 
response header. Figure D-1 on page D-2 
shows the RH formats and summarizes’ the 
allowed values. 


The control fields in the request header 
include: 


Request indicator 

RU Category 

Format indicator 

Sense Data Included indicator 
Chaining Control 

Form of Response Requested 
Queued Response indicator 
Pacing tndicator 

Bracket Control 

Change Direction indicator 
Code Selection indicator 
Enciphered Data indicator 
Padded Data indicator 


The control fields in the response header 
include: 


Response indicator 

RU Category 

Format indicator 

Sense Data Included indicator 
Chaining Control 

Response Type indicator 
Queued Response indicator 
Pacing indicator 


The above RH control fields are described 
below. 


Request/Response Indicator (RRI): Denotes 
whether this is a request or a response. 


RU Category: Denotes that the BIU belongs to 
one of four categories: session control 
(SC), network control (NC), data flow control 
(DFC), or function management data (FMD). 
(The NC category is not supported by T2.1 
nodes. ) 


Format Indicator: 


Indicates which of two 
formats (denoted Format 1 and Format 0) is 
used within the associated RU (but not 
including the sense data field, if any; see 
Sense Data Included indicator, below). 


For SC, NC, and DFC RUs, this indicator is 
always set to Format 1. 


For (SSCP,PU) and (SSCP,LU) sessions, Format 
1 indicates on FMD requests that the request 
RU includes a network services (NS) header 
and 1s field-formatted (with various 
encodings» such as binary data or 
bit-significant data, in the individual 
fields). Format 0 indicates that no NS head- 
er is contained in the request RU and the RU 
is character-coded. The Format indicator 
value on a response is the same as on the 
corresponding request. 


For LU-LU sessions that support FM headers on 
FMD requests, Format 1 indicates that an FM 
header is present. The Format indicator is 
always set to 0 on positive responses. 


Sense Data Included Indicator (SDI): Indi- 
cates that a 4-byte sense data field is 
included in the associated RU. The sense 
data field (when present) always immediately 
follows the RH and has the format and meaning 
described in Appendix G. Any other data con- 
tained in the RU follows the sense data 
field. Sense data is included on negative 
responses and on EXRs, where it indicates the 


type of condition causing the exception. 


(The Format indicator does not describe or 
affect the sense data, which is always in the 
4-byte format shown in Appendix 6G.) 


Chaining Control: Indicates that a sequence 
of contiguous transmitted requests 1s being 
grouped in a chain. Two indicators, Begin 
Chain indicator (BCI) and End Chain indicator 
(ECI), together denote the relative position 
of the associated RU within a chain. The 1 
values of these indicators (BCI = 1 and ECI = 
1) are referred to as BC and EC, respective- 


ly. 


(BC, ~EC) = first RU in chain 


(-BC, -EC) middle RU in chain 


(-BC, EC) = last RU in chain 


(BC, EC) only RU in chain 


Responses are always marked "only RU in 
chain." 


Form of Response Requested: In a request 
header, defines the response protocol to be 
executed by the request receiver. 
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Reauest Header 


Byte 0 I Byte 1 | Byte 2 | 

RU | | | | - | 

RRI Category FI SDI BCI ECIIDRII © DR2I ERI QRI PI [BBI EBI CDI ——«CSE_EDI PDI CEBT! 
= of | irl ?|¢dét #4 jr Pb Pedtet ¢ = = EF tet ft 


co @6 CF 
ee 88 66 


Response Header 


RU l 


Category FY spr 1 1 IDRIT DR2I RTI | 
i oe ee Petbetebetdebedede 
Field Description Explanation/Usage 
RRI Request/Response indicator 0 = request (RQ); 1 = response (RSP) 


FM data (FMD) 10 
network control (NC) il 


data flow control (DFC) 


RU Category Request/Response Unit Category 00 
| session control (SC) 


ol 


“oon 


FY Format indicator 0 = no FM header (-FMH), for LU-LU sessions; or 
character-coded without an NS header (-NSH); 
for network services (NS) 
1 = FM header (FMH) follows, for LU-LU sessions}; or 
field-formatted with an NS header (NSH), for NS 


- SOI Sense Data Included indicator 0 = not included (-SD); 1 = included (SO) 

BCI Begin Chain indicator 6 = not first in chain (~BC)$; 1 = first in chain (BC) 
ECT End Chain indicator © = not last in chain (-EC)3; 1 = last in chain (EC) 
: DDRII Definite Response 1 indicator 0 = ~DR1; 1 = DRI 
» DR2I Definite Response 2 indicator 0 = -DR2; 1 = DR2 

ERI Exception Response indicator Used in conjunction with DRII and DR2I to indicate, 

in a request, the form of response requested: 

(DRII, DR2I, ERI} = 000 means no-response requested 
= 10010101110 means definite-response requested 
= LOLIOILE111 means exception-response requested 

RTI Response Type indicator 0 = positive (+)3 1 = negative (-) 

QRI Queued Response indicator 0 = response bypasses TC queues (~QR)3 

| 1 = enqueue response in TC queues (QR) 

PT Pacing indicator O = ~PAC; 1 = PAC 

BBI Begin Bracket indicator 0 = ~BB; 1 = BB 

 EBI End Bracket indicator 0 = ~EB; 1 = EB (reserved for LU type 6.2) 
cor Change Direction indicator 0 = do not change direction (~CO)3 
. 1 = change direction (CD) 

cSI Code Selection indicator 0 = code 03 I = code 1 

EDI Enciphered Data indicator 0 = RU is not enciphered (~ED); 1 = RU ts enciphered (ED) 

POI Padded Data indicator 0 = RU is not padded (-PD)3; 1 = RU is padded (PD) 

cEBI Conditional End Bracket 0 = not conditional end bracket (-CEB); 1 = conditional 


indicator end bracket (CEB) (used for LU type 6.23 else, reserved) 
= Reserved 


Figure D-1. RH Formats 


D-2 SNA Forwat ard Protocol Reference Manual for LU Type 6.2 


Three bits in a request header specify the 
form of response that is desired. They are: 
Definite Response 1 indicator (ORII), Defi- 
nite Response 2 indicator (DR2I), and the 
Exception Response indicator (ERI). They can 
be coded to request: 


1. No-response, which means that a response 
will not be issued by the half-session 
receiving the request. (DRII,DR2I) = 
(0,0) = (-DR1,~DR2) and ERI=0 is the only 
coding possible; the abbreviation RQN 
refers to a request with this coding. (A 
special response, ISOLATED PACING 
RESPONSE (IPR), does set 
[DRII,DOR2I,ERII=10,0,0], but it is used 
independently of the other responses 
listed. IPR is sent in connection with 
session-level pacings the sequence number 
in its associated TH does not correlate 
1t to any given request. ) 


2. Exception response, which means that a 
negative response will be issued by the 
half-session receiving the request only 
in the event of a detected exception (a 
positive response will not be issued). 
(ORII, OR2T) = (1,0)100,1)10151) and 
ERI=1 are the possible codings; RQ@El, 
RQE2, and RQE3 are the abbreviations, 
respectively; the abbreviation RQE or 
RQE*X refers to a request with any of 
these codings. 


3. Definite response, which means that a 
response will always be issued by the 
half-session receiving the request, 
whether the response 1s positive or nega- 
tive. (DRIIT, DR2I) = (1,0)100,1)101,1) 
and ERI=0 are the possible codings; RQDI, 
RQ02, and RQO3 are the abbreviations, 
respectively; the abbreviation RQO or 
RQO* refers to a request with any of 
these codings. 


A request that asks for an exception response 
or a definite response has one or both of the 
DRII and OR2I bits set to | (three combina- 
tions); a response to a request returns the 
same (DRII, OR2ZI) bit combination (see Fig- 
ure D-2 on page D-4). 


The setting of the DRII, DR2I, and ERI bits 
varies by RU category. Chapter 4 and Chap- 
ter 6.2 define the settings for SC; Chapter 
6.1 defines them for DFC3 Chapter 4 defines 
them for network services FMD. 


In the case of LU-LU sessions, BIND parame- 
ters (see Appendix £) specify the form of 


response to be raquested during the sessions 
see Chapter 2 and Chapter 5.3, as well as 
Figure D-2 on page D-4. 


The (DRII, OR2I, ERI) = (0, 0; 1) combination 
is reserved. 


Queued Response Indicator (QRI): In a 
response header for a normal-flow RU, the 
Queued Response indicator denotes whether the 
response is to be enqueued in TC queues: 
QRI=QR, or whether it 1s to bypass these 
queues: QRI=-QR. In a request header for a 
normal-flow RU, it indicates what the setting 
of the QRI should be on the response, if any,» 
to this request (i.e., the values on the 
request and response are the same). 


For expedited-flow RUs, this bit is reserved. 


The setting of the QRI bit is the same for 
all RUs in a chain. 


Response Type: In a response header, two 
basic response types can be indicated: posit- 
tive response or negative response. For neg- 
ative responses, the RH is always immediately 
followed by four bytes of sense data in the 
RU. Thus, RTI=NEG and RTI=POS occur jointly 
with SDI=SD and SOI=“S)0, respectively. 


Three Kinds of positive and negative 
responses correspond to the three valid 
(DRII, DR2I) combinations allowed on 
requests. The settings of the DRII and DR2I 
bits in a response always equal the settings 
of the ORII and ODR2I bits of the 
form-of-response-requested field of the cor- 
responding request header, except as shown in 
Figure D-2 on page 0-4. 


Pacing: In a request header, the Pacing 
Request indicator denotes that the sending TC 
element can accept a Pacing Response indica- 
tor. 


The Pacing Response indicator in a response 
header is used to indicate to the receiving 
TC element that additional requests may be 
sent on the normal flow. The Pacing Response 
indicator may be on in an RH that is attached 
to a response RU on the normal flow; or, if 
desired, a separate, or isolated, response 
header may be used, to which no RU is 
attached. This latter RH signals only the 
pacing response; it is called an ISOLATED 
PACING RESPONSE (see Chapter 6.2). Isolated 
and nonisolated pacing responses are func- 
tionally equivalent. 
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NOTES: 


RQD1I=(1,0,0) 


(Used by DFC) 


RQE1=(1,0,1) 
(Used by 
DFC and PS) 
RQD213=(%,1,0) 
RQE2/13=(*,15,1) 
(Used by PS) 


RQN =(9,3,0) 


(Not used) 


| REQUEST VALID RESPONSE | MEANING OF RESPONSE | 


+RSP1=(1,0,0) 
~RSP1=(1,0,1) 


-RSP1=(1,0,1) 


+RSP2 [3=(%,1,0) 
~RSP2|3=(*,1,1) 


implied +RSP2|3 


-RSP2|3=(%,15,1) 


positive response 
negative response 


negative response 


confirmed 
not confirmed 


reply received with no inter- 
vening response 
not confirmed 


1. Values displayed in this table are in the order (DRII,DR2I,ERI) for requests and (DRII,DR2I,RTI) 
for responses. 


2. All -EC requests are sent as RQE1l. 


Figure D-2. 


Bracket Control: Used to indicate the begin- 
ning or end of a group of exchanged requests 
and responses called a bracket. Bracket pro- 
tocols are used only on LU-LU sessions. When 
used, BB appears only on the first request in 
the first chain of a bracket; CEB appears 
only on the last request of the last chain of 
a bracket. (When bracket usage is specified 
in BIND, the BIND request carries an implied 
BB.) The bracket indicators are set only on 
LUSTAT and FMD requests, and are thus sent 
normal-flow. See Chapter 6.1 for detailed 
discussion of bracket protocols. 


Change Direction Indicator (CDI): Used when 
there is half-duplex (HDX) control of the 
normal flows within a session (not to be con- 
fused with link-level HDX protocols). It 
permits a sending half-session to direct the 
receiving half-session to send. The HDX pro- 
tocol is useful to half-sessions with limited 
input/output capabilities that cannot simul- 
taneously send and receive user data. When 


used, CD appears only on the last request in 


a chain; it its set only on LUSTAT and FMD 
requests. See Chapter 6.1 for detailed dis- 
cussion of this protocol. 


FMD Request/Response Combinations for Sessions between Two LU 6.2s 


Code Selection Indicator (CSI): Specifies 
the encoding used for the associated FMD RU. 


When a session is activated, the 
half-sessions can choose to allow use of two 
codes in their FMD RUs (e.g., EBCDIC and 


ASCII), which they designate as Code 0 and 
Code 1. FM headers and request and response 
codes are not affected by the Code Selection 
indicator. 


For SC, WNC, 
reserved. 


and OFC RUs, this bit is 


Enciphered Data Indicator (EDI): Indicates 
that information in the associated RU is 
enciphered under session-level cryptography 
protocols. 


Padded Data Indicator (PDI): Indicates that 
the RU was padded at the end, before 
encipherment, to the next integral multiple 
of 8 bytes in length; the last byte of such 
padding is the count of pad bytes added, the 
count being a number (1-7 inclusive) in 
unsigned 8-bit binary representation. 
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APPENDIX E. EST/RESP UNIT (RU) FORMATS 


This appendix defines detailed RU formats. A categorized list of RU abbreviations is presented 
first, followed by an alphabetic list of request RU format descriptions, a summary of response 
RUs, and a list of response format descriptions for those positive response RUs that return data 
in addition to the request code. Two final sections describe control vectors and session keys. 


The initial line for each RU in the two RU format description lists is in one of the following 
formats: 


Requests 


"RU ABBREVIATION; Origin NAU-->Destination NAU, Normal (Norm) or Expedited (Exp) Flows RU Cate- 
gory (RU NAME)" 


Responses 
“RSPC(RU ABBREVIATION)$ Origin NAU-->Destination NAU, Norm or Exp Flows RU Category” 


1. "RU Category" is abbreviated as follows: 
DFC data flow control 
sc session control 
FMD hS(ma) function management data, network services, maintenance services 
FMD N5(s) function management data, network services, session services 


2. The formats of character-coded FMD NS RUs are implementation dependant; LU-->LU FMD RUs 
(e.g.» FM headers) are described in "Appendix H. FM Header and LU Services Commands" . 


3. All values for field-formatted RUs that are not defined in this section are reserved. 


G4. The request code value X'FF' and the NS header values X'(3I7IBIF)F¥%%%' = and 
X'*#*( 3171 BFF’ are set aside for implementation internal use, and will not be otherwise 
defined in SNA. 


5. Throughout this appendix the following symbol-string types are used: 


® Type-A (Assembler oriented): a byte string consisting of one or more EBCDIC uppercase 
letters (A through Z), numerics (0 through 9), $, #, and a, the first character of which 
1S nonnumeric. 


e §€6Type-USS ("unformatted system services" or character-coded subset of the SNA character 
set): a byte string consisting of one or more EBCDIC uppercase letters (A through Z), 
numerics (0 through 9), $, #, 3 line feed (X'15'), space (X'460') and the following 11 
special characters: ‘'=(),+-%./& with no restriction on the first character. 


® Type-AE (A extended): a byte string consisting of one or more EBCDIC lowercase letters 
(a through 2), uppercase letters (A through Z), numerics (0 through 9), $, #, a) and 
period (.), with no restriction on the first character. 


®  Type-6GR (EBCDIC graphics): a byte string consisting of one or more EBCDIC characters in 
the range X'41' through X'FE', with no restriction on the first character. 


® Type-G (general): a byte string consisting of one or more bytes of binary values 0 
through 255. 


The RU field to phich a type-A, type-AE, or type-GR symbol string is assigned may be longer 
than the symbol string; in this case, the symbol string is left-justified within the field, 
which is filled out to the right with space (X'40') characters. Space characters, if pres- 
ent, are not part of the symbol string. If the symbol string is formed from the concat- 
enation of two or more individual symbol strings, such as the fully-qualified LU name, the 
concatenated symbol string as a whole is left-justified within the field ,which is filled 
out to the right with space characters. Space characters, if present, are not part of the 
concatenated symbol string. 
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Throughout this appendix, reserved is used as follows: reserved bits, or fields, are cur- 
rently set to 0's (unless explicitly stated otherwise); reserved values are those that cur- 
rently are invalid. Correct usage of reserved fields is enforced by the sender; no receive 
checks are made on these fields. 


Throughout this appendix, retired fields and values are those that were once defined by SNA 
but are no longer defined. To accommodate implementations of back-level SNA, current imple- 
mentations of SNA treat retired fields as follows: send checks enforce the setting of 
retired fields to all O's except where other unique values are required (described individ- 
ually in this appendix); no receive checks are made on these fields, thereby accepting 
back-level settings of these fields. Special handling of retired fields, such as echoing or 
passing on retired fields as received, is discussed where appropriate. 
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SUMMARY OF REQUEST RU'S 


Y CATEGORY 


sc 
*ACTLU CRV DACTLU UNBIND 
*BIND 
DFC 
BIS LUSTAT RTR SIG 
FMD NS(ma) 
ECHOTEST REQECHO 
FMD NS(s) 
BINDF CTERM SESSEND TERM-SELF 
*CINIT INIT-SELF SESSST UNBINDF 
CLEANUP NOTIFY 


* These request RUs require response RUs that, if positive, may contain data in addition to the NS 
header or request code. See ‘Summary of Response RU's" on page E-18 and "Positive Response RU's with 
Extended Formats" on page E-18 . 
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INDEX OF RU'S BY NS HEADERS AND REQUEST CODES 


Within DFC, SC, or any specific FMD NS category, the request code is unique. However, while a request 
code has only one meaning in a specific category, a given code can represent different requests in sepa-_ 
rate categories. 


FMD NS Headers (Third byte is the request code) 


X'810387' REQECHO 

X'810389'" ECHOTEST 

X'810601' CINIT 

X'810602' CTERM 

X'810620' NOTIFY (SSCP<-->LU) 
X'810629' CLEANUP 

X'810681' INIT-SELF (Format 1) 
X'810683' TERM-SELF (Format 1) 
X'810685' BINDF 

X'810686' SESSST 

X'810687' UNBINDF 


X'810688' SESSEND 


DFC Request Codes 


X'04' LUSTAT 
X'05' RTR 
X'70° BIS 
Xx'c9' SIG 


SC Request Codes 


X'OD' ACTLU 
X'OE' DACTLU 
X'31' BIND 
X'32' . UNBIND 
X'CO' CRV 
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ACTLU 


REQUEST RU FORMATS 


ACTLUs SSCP-->LU, Exp; SC (ACTIVATE LOGICAL UNIT) 


ACTLU is sent from an SSCP to an LU to activate a session between the 
SSCP and the LU and to establish common session parameters. 


0 X'OD’ request code 

1 Type activation requested: 
X'O01' cold 
X'O2' ERP 

2 bits 0-3, FM profile: 


X'O' FM profile 0 
X'6' FM profile 6 
bits 4-7, TS profile: 
X'1' TS profile 1 (only value defined) 


BIND; PLU-->SLU, Exp; SC (BIND SESSION) 


BIND is sent from a primary LU to a secondary LU to activate a session 


between the LUs. The secondary LU uses the BIND parameters to help 
determine whether it will respond positively or negatively to BIND. 


0 X'31' request code 
1 bits 0-3, format: 0000 
bits 4-7, type: 
0000 negotiable 


2 FM profile: 
X'13' FM profile 19 
3 TS profile: 


X'07' TS profile 7 
FM Usage—Primary LU Protocols for FM Data 
4 bit 0, chaining use selection: 
1 multiple-RU chains allowed from primary LU half-session 
bit 1, request control mode selection: 
0 immediate request mode 
bits 2-3, chain response protocol used by primary LU half-session for FMD requests; 
chains from primary will ask for: 
ll definite or exception response 
bits 4-6, reserved 
bit 7, send End Bracket indicator: 
0 primary will not send EB 


re en ee) 


1 multiple-RU chains allowed from secondary LU half-session 
bit 1, request control mode selection: 
06 immediate request mode 
bits 2-3, chain response protocol used by secondary LU half-session for FMD requests; 
chains from secondary will ask for: 
ll definite or exception response 
bits 4-6, reserved 
bit 7, send End Bracket indicator 
0 secondary will not send EB 
EM Usage—Common LU Protocols 
6 bit 0, session segmenting support: 
0 this LU supports reception of segments on this session 
1 this LU does not support reception of segments on this session; the BIND 
sender and receiver set the maximum RU sizes, in bytes 10-11 of BIND and 
RSP(BIND), so that segmenting will not occur on the link for this session 
bit 1, FM header usage: 
1 FM headers allowed 
bit 2, brackets usage and reset state: 
0 brackets are used and bracket state managers' reset states are INB 
bit 3, bracket termination rule selection 
1 Rule 1 (conditional termination) will be used during this session 
bit 4, alternate code set allowed indicator: 
0 alternate code set will not be used 
1 alternate code set may be used 
bits 5-6, reserved 
bit 7, BIND response queue capability: 
0 BIND response cannot be held/queued 


i 
iu 
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BIND 


E-6 


10 


Il 


12 


13 


14 


15 


16-22 


PS Profile 


1 BIND sender allows bind receiver to queue BIND and withhold BIND response 
for an indefinite period i | 
Note: BIND sender may provides: a timer or operator interface to send UNBIND if 
session activation time exceeds BIND sender's limits. BIND queuing is termi- 
nated by sending UNBIND to the BIND receiver. 
bits 0-1, normal-flow send/receive mode selection: 
10 half-duplex flip-flop 


bit. 2, recovery responsibility: 


1 symmetric responsibility for recovery 
bit 3, contention winner/loser: 
0 secondary is contention winner and primary is contention loser 
1 primary is contention winner and secondary is contention loser 
Note: Contention winner is also brackets first speaker. 
bits 4-5, alternate code processing identifier (reserved unless Alternate Code Set 
Allowed indicator (byte 6, bit 4) is 1): | 
01 process alternate code FMD RUs as ASCII-8 
Note: When the Alternate Code Processing Identifier indicator is set to the 
value 01, the entire FMD request RU is to be translated using the transforms 
defined by the ANSI X3.26 Hollerith Card Code. 
bit 6, reserved 
bit 7, half-duplex flip-flop reset states: 
1 HDX-FF reset state is SEND for the primary and RECEIVE for the secondary 
(e.g., the primary sends normal-flow requests first after session acti- 
! vation) | 
IS Usage 
bit 0, staging indicator for secondary TC to primary TC normal flow: 
0 pacing in this direction occurs in one stage (only value used for 
PNCP-mediated sessions ) 
l pacing in this direction occurs in more than one stage 
Note: The meanings of 0 and 1 are reversed from the staging indicator for 
primary TC to secondary TC. 
bit 1, reserved | | 
bits 2-7, secondary TC's send window size: 0 means no pacing of requests flowing from 
the secondary , | 
bits 0-1, reserved 
bits 2-7, secondary TC's receive window size: a value of 0 causes the boundary fune- 
tion to substitute the value set by a system definition pacing parameter (if 
the system definition includes such a parameter) before it sends the BIND RU 
on to the secondary half-session; a value of 0 received at the secondary is 
interpreted to mean no pacing of requests flowing to the secondary 
Maximum RU size sent on the normal flow by the secondary half-session: bit 0 is set 
to 1, and the byte is interpreted as X'ab' = ae2xxb. (By definition, a28 and there- 
fore X'ab' is a normalized floating point eraser eet }) See Figure E-1 on page E-8 
for all. possible values. 
Maximum RU size sent on the normal flow by the primary half-session: identical encod- 


ing.as described for byte 10 


bit 0, staging indicator for primary TC to secondary 1c normal flow: 
l pacing in this direction occurs in one stage (only value used for 
PNCP-mediated sessions) 
0 pacing in this direction occurs in two stages. 
Note: The meanings of 0 and 1 are reversed from the staging indicator for 
secondary to primary TC. 
bit 1, reserved 
bits.2-7, primary TC's send window size: a value of 0 causes the value set by a sys- 
tem definition pacing parameter (if the system definition includes such a 
parameter) to be assumed for the session; if this 1s also 0, it means no 
pacing of requests flowing from the primary. (For single-stage pacing in 
the primary-to-secondary direction, this field is redundant with, and indt- 
cates ‘the same value as, the secondary TC's receive window size—see byte 9, 
bits 2-7, above.) 
bits 0-1, reserved | 
bits 2-7, primary TC's receive slindow size: a value of 0 means no pacing of requests 
flowing to the primary. (For single-stage pacing in the secondary-to-pri- 
mary direction, this field is redundant with, and indicates the same value 
as, the secondary TC's send window size—see byte 8, bits 2-7, above. ) 


bit 0, PS Usage field format: 
0 basic format . 
bits i- 7 LU type: 
0000110 LU type 6 
PS Usage characteristics 


LU-6 level: 


X'02' Level 2 Ci. exs LU ae 2) 
Reserved 
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23 


24 


25 


26-k 


26 


27 


28-k 


k+l 
K+2-m 
m+1 


m+2-n 
m+2 


mt3-n 
n+] 


n+2-p 


BIND 


bits 0-2, retired 
bit 3, conversation-level security support: 
0 Access Security Information field will not be accepted on incoming FMH-5s 
1 Access Security Information field will be accepted on incoming FMH-5s 
bits 4-5, reserved 
bit 6, already-verified function support: 
0 Already Verified indicator will not be accepted on incoming FMH-5s 
1 Already Verified indicator will be accepted on incoming FMH-5s 
bit 7, reserved 
bit 0, reserved 
bits 1-2, synchronization level: 
01 confirm is supported 
10 confirm, sync potnc, and backout are supported 
bit 3, reserved 
bits 4-5, responsibility for session reinitiation: 
00 operator controlled 
01 primary half-session will reinitiate 
10 secondary half-session will reinitiate 
1l either may reinitiate 
Note: Bits 4-5 are reserved when bit 6 of this byte is set to l. 
bit 6, parallel session support for LU-LU pair: 
0 not supported 
1 supported 
bit 7, Change Number of Sessions GDS variable flow support (set to 1 if byte 24, bit 
6 = 1): 
0 not supported 
1 supported 
Note 1: fields defined by bits 0-5 are consistent with the corresponding fields in 
other BINDs used for the same (partner LU, mode name) pair. 
Note 2: fields defined by bits 6-7 are consistent with the corresponding fields in 
other BINDs used for the same partner LU. 
Reserved 
End of PS Usage Field 
Cryptoqraphy Options 
Note: Cryptography usage is consistent for all parallel sessions with the same (part- 
ner LU, mode name) pair. 
bits 0-1, reserved 
bits 2-3, session-level cryptography options: 
00 no session-level cryptography supported 
11 session-level mandatory cryptography supported; all cryptography key man- 
agement is supported by the SSCP and LU; exchange (via +RSP(BIND)) and 
verification (via CRV) of the cryptography session-seed value 1s sup- 
ported by the LUs for the session; all FMD requests are enci- 
phered/deciphered by TC 
bits 4-7, session-level cryptography options field length: 
X'0' no session-level cryptography specified; additional cryptography 
options fields (bytes 27-k) omitted 
X'9' session-level cryptography specified; additional options follow in next 
nine bytes 
bits 0-1, session cryptography key encipherment method: 
00 session cryptography key enciphered under SLU master cryptography key 
using a seed value of 0 
bits 2-4, reserved | 
bits 5-7, cryptography cipher method: 
000 block chaining with seed and cipher text feedback, using the Data 
Encryption Standard (DES) algorithm 
Session cryptography key enciphered under secondary LU master cryptography key; an 
eight-byte value that, when deciphered, yields the session cryptography key used for 
enciphering and deciphering FMD requests 
Length of primary LU name (values 0 to 17 are valid) 
Note: X'00' = no primary LU name present. 
Primary LU name or, if the secondary LU issued the INIT-SELF, the uninterpreted name 
as carried in that RU 
Length of user data 
User data 
User data key: 
X'00' structured subfields follow 
Note: Individual structured subfields may be omitted entirely. When present, 
they appear in ascending field number order. 
Structured subfields. (For detailed definitions, see "User Data Structured Subfield 
Formats" on page E-16 .) 
Length of user request correlation (URC) field (values 0 to 12 are valid) 
Note: X'00' = no URC present. 
URC: LU-defined identifier (present only if carried in INIT from SLU) 
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BINO 


ptl Length of secondary LU name (values 0 to 17 are valid) 
Note: X'00' = no secondary LU name present. 
pt2-r Secondary LU name 


Note 1: The length of the BIND RU cannot exceed 256 bytes, lest a negative response be 
returned. | | 


Note 2: If the last byte of a request is a length field and that field is 0, that byte may be 
omitted from the BINO request. 


Mantissa (a). 


A B C D E F 


(10) C12) €212) (23) C14) (25) 


=~ 
re 
#+) 
-— 
ae 
£ 
roy 
oO 


0 176 192 208 224 240 


512 576 640 704 768 832 896 960 
1024 0«=6. 1152) 1280)sd1408) = =61536)0= = 166%) 17921920 
20468 2304 2560 2816 3072 3328 3584 3840 


4096 4608 5120 5632 6144 6656 7168 7680 


8192 9216 10240 11264 12288 13312 14336 15360 


262144 294912 327680 360448 393216 425984 458752 491520 


E 


te: A value of X'ab' in byte 10 or byte 11 of BIND represents ae2*%b. For example, X'C5' 
represents (in decimal) 1L2e2%*5 = 384. 


Figure E-1. RU Sizes Corresponding to Values X'ab' in BIND 


E~- 


 & 
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BINDF 


BINDF; PLU-->SSCP, Norm; FMD NS(s) (BIND FAILURE ) 


oe 
on 


BINDF is sent, with no-response requested, by the PLU to notify the 


SSCP that the attempt to activate the session between the specified 
LUs has fatled. 


X'810685' NS header 

Sense data 

Reason: 

bit 0, reserved 

bit .1, 1 BIND error in reaching SLU 

bit 2, 1 setup reject at PLU 

bit 3, 1 setup reject at SLU 

bits 4-7, reserved 

Session key, as described in the section "Session Keys" on page E-23 
Note; One of the following session keys is used: 

X'07' network address pair: PLU and SLU, respectively 

X'15' network-qualified address pair: PLU and SLU, respectively 


BIS; LU-->LU, Norm; DFC (BRACKET INITIATION STOPPED) 


0 


BIS is sent by a half-session to indicate that it will not attempt to 
begin any more brackets. 


X"70' request code 


CINIT; SSCP-->PLU, Norm; FMD NS(s) (CONTROL INITIATE) 


5-9 


10-11 
l2-m 


utl-n 
m+] 

mt2 
mt+3—-nrn 
nt+l-ne2 
n+3-r 
n+3 


n+4-r 
r+Ii-s 
rtl-re2 


r+3-s 
s+] 


CINIT requests the PLU to attempt to activate, via a BIND request, a 
session with the specified SLU. 


X'810601' NS header 
Format 
bits 0-3, 0000 Format 0 (only value defined) 
Note: CINIT format 0 may carry control vectors at the end of the basic 
RU, 

bits 4-7, reserved 
bit 0, INITIATE origin: 

0 ILU is OLU 

1 ILU is not OLU 
bit 1, reserved 
bit 2, origin LU: 
0 SLU is OLU 
1 PLU is OLU 
initiator: 
0 network user is the initiator 
1 network manager is the initiator 
bits 4-7, reserved 
Session Key, as described in the section "Session Keys" on page E-23 
Note: The following session key is used: 
X'O7' network address pair: PLU and SLU, respectively 


bit 3, 


Note: If control vector X'15' is supported by the LU, then bytes 5-9 are 
reserved; otherwise, these bytes contain session key X'07' when sent from the 


SSCP to a subarea LU. 
Length, in binary», of BIND Image field 


BIND image: bytes l-p of the BIND RU, j.e., through the URC field (see BIND format 


description) 

Note: The URC Lenyth field is included, even if it is set to 0. 
Name of SLU 

Type: X'F3' logical unit 


Length, in binary, of symbolic name (1-8 characters ) 

Symbolic name, in EBCDIC characters 

Retired—set to X'0000' 

User Field 

Length» in binary, of user data 

Note: X'00' = no user data 1s present. 

User data (retired for LU 6.2——not sent by current-level tmplemantation) 
LU or Non-SNA Device Specifications 

Length, in binary, of Characteristics field 

Note: X'0000' = no Characteristics field is present. 

Characteristics field (retired for LU 6.2—not sent by current-level implementation) 
Length of Session Cryptography Key field 

Note: X'00' = no Session Cryptography Key field present. 
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CINIT 


E-10 


s+2-t Session Cryptography Key field: session cryptography key enciphered under PLU master 
cryptography key 
Note: End of base RU 


tel-u Control vector, as described in the section "Control Vectors" on page E-20 
Note: The following vector Keys are used in CINIT: 
X'OD' Mode/Class of Service/Virtual Route List (this control vector is always present) 
X'15' network-qualified address pair: PLU and SLU, respectively (This control vector 
is always present when using extended network addressing; otherwise, it is 
optional.) 


CLEANUP; SSCP-->SLU, Norms FMD NS(s) (CLEAN UP SESSION) 


CLEANUP is sent by the SSCP to an LU (in a subarea node or BF for 
peripheral LU) requesting that the LU or BF attempt to deactivate the 
session for the specified (PLU,SLU) network address pair. 


~-2 X'810629' NS header 
bits 0-3, 0000 Format 0 
bits 4-7, reserved 
Reserved 
Reason: 
bit 0, 0 network user 
1 network manager 
bit 1, 0 normal 
1 abnormal 
bits 2-7, reserved 
6-n Session key, as described in the section "Session Keys" on page E-23 
Note: One of the following session keys is used: 
X'07' network address pair: PLU and SLU, respectively 
X'15' network-qualified address pair: PLU and SLU, respectively 


7 a Wo 


CTERM; SSCP-->PLU, Norm; FMD NS(s) (CONTROL TERMINATE ) 


CTERM requests that the PLU attempt to deactivate a session identified 
by the specified (PLU,SLU) network address pair. 


0-2 X'810602' NS header 

3 bits 0-3, 0000 Format 0 
bits 4-7, reserved 

& Type: 


bits 0-1, reserved 
bits 2-3, 00 reserved 
01 orderly 
10 forced 
11 reserved 
bits 4-7, reserved 
5 Reason: 
bit 0, 0 network user 
1 netuork manager 
bit 1, 0 normal 
1 abnormal 
bits 2-7, reserved 
Reservad 
Session key, as described in the section "Session Keys" on page E-23 
Note: One of the following session keys is used: 
X'07' network address pair: PLU and SLU, respectively 
X'15' network-qualified address pair: PLU and SLU, respectively 
m+l-mt2 Retired: set to X'0000' 


ad 
ZN 


CRV; PLU-->SLU, Exp; SC (CRYPTOGRAPHY VERIFICATION) 


CRV, a valid request only when session-level cryptography was selected 
in BIND, is sent by the primary LU session control to verify 
cryptography security and thereby enable sending and receiving of FMD 
requests by both half-sessions. 


0 X'CO' request code 

1-8 A transform of the (deciphered) cryptography session-seed value received (enciphered) 
in bytes 28-k of +#RSP(BIND), re-enciphered under the session cryptography key using a 
seed value of 0; the transform is the cryptography session-seed value with the first 
four bytes inverted 
Note; The cryptography session-seed is used as the seed for all session-level 
cryptography encipherment and decipherment provided for FMD RUs. 
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DACTLU 


DACTLU; SSCP-->LU, Exp; SC (DEACTIVATE LOGICAL UNIT) 


DACTLU is sent to deactivate the session between the SSCP and the LU. 


X'OE’ 


request code 


Note: End of short (Cone-byte) request. 


ECHOTEST; 


0 
3 
3 
4 


INIT-SELF 


Type of deactivation requested: 


X'OL' 
X'03' 
Cause 
X'07' 
x'08' 
X'09' 
X'OB' 
X'Oc' 


X'OD' 


X'OE' 


X' OF 


normal, deactivation 

session outage notification (SON) 

(reserved if byte 1 * X'03'): 

virtual route inoperative: the virtual route serving the SSCP-LU session has 
become inope: ative, thus forcing the deactivation of the session 

route extension inoperative: the route extension serving the SSCP-LU session 
has become inoperative, thus forcing the deactivation of the session 
hierarchical reset: the SSCP-LU session is being deactivated because of a 
+RSPCACTPU, Cold) 

virtual route deactivated: the SSCP-LU session is being deactivated because of 
a forced deactivation of the virtual route being used by the session 

SSCP or LU failure—wumrecoverable: the SSCP-LU session had to be reset because 
of an abnormal termination; recovery from the failure was not possible 

session override: the SSCP-LU session has to be deactivated because of a more 
recent session activation request for the SSCP to subarea PU session over a dif- 
ferent virtual route 

SSCP or LU failure—recoverable: the SSCP-LU session had to be deactivated 
because of an abnormal termination of the SSCP or LU of the session; recovery 
from the failure may be possible 

cleanup: the SSCP is resetting its half-session before receiving the response 
from the LU being deactivated 


SSCP-->LU, Norm; FMD NS(ma) (ECHO TEST) 


ECHOTEST carries test data to the target LU; the test data is the same 


as 


that carried in the corresponding REQECHO. 


X'810389" NS header 
Echo data field: same as bytes 4-m in the soliciting REQECHO 
Number of data bytes 


Data 


Format 13; ILU-->SSCP, Norm; FMD NS(s) CINITIATE-SELF ) 


INIT-SELF from the ILU requests that the SSCP authorize and assist in 
the initiation of a session between the LU sending the request (that 


1S» 
request (the DLU). 


the ILU, sthich also becomes the OLU) and the LU named in the 


X'810681' NS header 
bits 0-3, format: 


0001 Format 1 


bits 4-7, reserved 


Type: 


bits 0-1, 01 initiate only (I): do not enqueue 


ll initiate/enqueue (I/Q): enqueue the request if it cannot be satisfied 
immediately 


bits 2-4, reserved 
bits 5-6, PLU/SLU specification: 


00 DLU is PLU 
01 DLU is SLU 


bit 7, reserved 
Queuing conditions for DLU: 
bit 0; 0 do not enqueue if session limit exceeded 


bit 


1 enqueue if session limit exceeded 


1, 0 do not enqueve if DLU is not currently able to comply with the PLU/SLU spec- 


ification (as given in byte 4, bits 5-6) 
1 enqueve if BLU is not currently able to comply with the PLU/SLU speci fica- 
tion , 


bits 2-4, reserved 
bits 5-6, queuing position/service: 


01 enqueue this request FIFO 


bit 7, reserved 


Note: 


Since queuing conditions are specified ner the DLU only, the following default 


values are used by SSCP(OLU) for the OLU: 
® Enqueue if session limit exceeded. 
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INIT-SELF Format 1 


E-12 


® Enqueue this request at the back of the queue (FIFO). 

6-7 Reserved 

8-15 Mode name: an eight-character symbolic name (implementation and installation depend- 
ent) that identifies the set of rules and protocols to be used for the session; used 
by the SSCP(SLU) to select the BIND image that will be used by the SSCP(PLU) to build 
the CINIT request 


16-n  Uninterpreted Name of DLU 

16 Type: X'F3' logical unit 

17 Length, in binary, of DLU name 
18-n DLU name EBCDIC character string 


n+1-n+2 Retired: set to X'0000' 
n+3-r(=n+3) Reserved 


r+l-s User Re equest Correlation (URC) Field 
r+] Length, in binary, of URC 
Note: X'00' = no URC. (The length field is rlteeved present. ) 
rt2-s URC: end-user defined identifier; this value can be returned by the SSCP in a subse- 


quent NOTIFY to correlate a given session to this initiating request 


LUSTAT; LU-->LU, Norm; DFC (LOGICAL UNIT STATUS) 


LUSTAT is used by one half-session to send up to Tour bytes of status 


information to its paired half-session. 


0 X'04' request code ' 
1-4 Status value + status extension field (two bytes each): 
X'0006'+'rrrr' no-op (used to allow an RH to be sent when no other request is avail- 
able or allowed) + reserved field 


NOTIFY; SSCP<-->LU, Norm; FMD NS(s) CNOTIFY) 


NOTIFY is used to send information between an SSCP and an LU. NOTIFY 


carries information in the form of a (vector key, vector data) pair. 


0-2 X'810620' NS header (for SSCP-->LU and LU-->SSCP) 

3-p One NOTIFY vector as described in detail below 

Note: One of the following vector keys is used: 

X'03' ILU/TLU Notification: sent by the SSCP to inform the sender of an INIT or TERM 
request of the status of the session 

X'0C' LU Session Services Capabilities: sent by the LU to inform the SSCP having an 
active session with the sending LU of ‘he current LU-LU session services capa- 
bility of that LU 


NOTIFY vectors (described zero-origin) 


ILU/TLU Notification NOTIFY Vector 


0 Key: X'03' 
1 Status: 
X'03' procedure error 
2-9 PCID: a unique value used as a session identifier 
10 Reason (defined for Status field value of X'03' only) 


Setup Procedure Error 
bit 0, 1 CINIT error in reaching the PLU 
bit 1, 1 BIND error in reaching the SLU 
bit 2, 1 setup reject at the PLU 
bit 3, 1 setup reject at the SLU 
bit 4, 0 setup procedure error 
bit 5, reserved 
bit 6, 1 setup reject at SSCP 
bit 7, reserved 
11-14 Sense data 7 
15-m Session key,» as described in ‘he section "Session Keys" on page E-23 
Note: One of the following session keys is used: 
X'06' network name pair: (PLU or OLU) and (SLU or DLU), respectively 
X'15' network-qualified address pair: PLU and SLU, respectively 


m+l-n User Request Correlation (URC) Field 
m+] Length, in binary» of the URC. 
m+2-n URC: end user defined identifier, specified in an INIT request; used to correlate the 


NOTIFY to the initiating requests 


LU-LU Session Services Capabilities NOTIFY Vector 


0 Key: X'OC' 
1 Length, in binary» ot Vector Data field 
2-m Vector Data 
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8-15( =m) 


NOTIFY 


bits 0-3, primary LU capability: 


0000 PLU capability is inhibited, sessions can neither be queued nor started 
0001 PLU capability is disabled, sessions can be queued but not started 

0010 reserved 

0011 PLU capability is enabled, sessions can be queued or started 


bits 4-7, secondary LU capability: 


0000 SLU capability is inhibited, sessions can neither be queued nor started 
0001 SLU capability 1s disabled, sessions can be queued but not started 

0010 reserved 

0011 SLU capability is enabled, sessions can be queued or started 


LU-LU session limit (where a value of 0 means that no session limit is specified) 
LU-LU session count: the number of LU-LU sessions that are not reset, for this LU, 
and for which SESSEND will be sent to the SSCP 
bit 0, parallel session capability: 
0 parallel] sessions not supported 
1 parallel sessions supported 
bit 1, reserved 
bit 2, SESSST capability in RSP(ACTLU) (reserved in NOTIFY): 
0 SESSST RU is suppressed if SLU 
1 SESSST RU is sent if SLU 
bits 3-7, reserved 
Retired (set to X'4040404040404040') or omitted 


REQECHO; LU-->SSCP, Norm; FMD NS(ma) (REQUEST ECHO TEST) 


3 


G-m 
G 
5-m 


REQECHO requests that the SSCP return to the LU in ECHOTEST the data 


included in REQECHO. 


X'810387' 


NS header 


Repetition factor: number of times the test data is to be echoed to the target LU 
Note: X'00' is not a valid repetition factor. 

Echoed Data Field 

Number of data bytes to be echoed 

Echoed data 


RTR3; LU-->LU, Norm; DFC (READY TO RECEIVE) 


0 


SESSEND ; 


SESSST; 


Note: 


RTR indicates to the bidder that it is now allowed to initiate a 


bracket. RTR is sent only by the first speaker. 


X'05' request code 


LU-->SSCP, Norm; FMD NS(s) (SESSION ENDED) 


SESSEND is sent, with no response requested, by the LU (or the bounda- 
ry function on behalf of the LU ina peripheral node) to notify the 


SSCP that the session between the specified LUs has been successfully 
deactivated. 


X'810688' 
bits 0-3, 


bits 4-7), 


NS header 


format: 
0010 format 2 
reserved 


Cause: indicates the reason for the deactivation of the LU-LU session (see UNBIND for 


values) 


Action indicating if any resultant action is to be taken and by whom: 
X'01' normal, no resultant automatic action 
Session key, as described in the section "Session Keys" on page E-23 


One of the following session keys is used: 


X'07' network address pair: PLU and SLU, respectively 
X'15' network-qualified address pair: PLU and SLU, respectively 


vated. 


SESSST is sent, with no response requested, by the LU (or the boundary 
function on behalf of the LU in) a peripheral node) to notify the SSCP 
that the session between the specified LUs has been successfully acti- 


LU-->SSCP, Norm; FMD NS(s) (SESSION STARTED) 


X'810686' NS header 


Format: 


X'00' Format 0: no control vectors present 
X'O1L' Format 1: control vectors present in bytes nti-p 
Session key,» as described in the section "Session Keys" on page E-23 
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SESSST 


E~14 


n+i-p 


Note: One of the following session keys is used: 


X'07' network address pair: PLU and SLU, respectively 
%'15' network-qualified address pair: PLU and SLU, respectively 


ote: End of Format 03 Forwat 1 continues below. 


One or more control vectors, as described in the section "Control Vectors" on page 
E-20 | 

Note: The following vector keys may be used in SESSST: 

X'1E’ VR-ER Mapping Data 

X'23' Local Form Session Identifier 


SIG; LU-->LU, Exp; OFC (SIGNAL) 


TERM-SELF 


ntl-n+2 
n+3-p 
n+3 


n+4-p 


SIG is an expedited request that can be sent between half-sessions, 
regardless of the status of the normal flows. It carries a four-byte 
value, of which the first two bytes are the signal code and the last 
two bytes are the signal extension value. 


X'C9' request code 
Signal code: 

X'0001' request to send 
Signal extension: 
X'0001' soft 


Format 13 TLU-->SSCP, Norms FMD NS(s) (TERMINATE-SELF ) 


TERM~SELF from the TLU requests that the SSCP assist in the termi- 
nation of one or more sessions between the sender of the request (TLU 


= OLU) and the DLU. 


X'810683' NS header 
bits 0-3, format: 
0001 Format 1 
bits 4-6, reserved 
bit 7, 1 indicates that byte 3, bits 0-3, contain the format value 
Type: 
bits 0-1, 01 the request applies to active, pending-active, and queued sessions 
bit 2, reserved if byte 4, bit 7 = 13 otherwise: 
0 forced termination—session to be deactivated immediately and uncondi- 
tionally 
1 orderly termination—permitting an end-of-session precedure to be executed 
at the PLU before the session is deactivated | 
bit 3, 1 send DACTLU to OLU when appropriate; no further session initiation request 
will be sent (from this sender) for OLU 
bit 4, reserved 
bits 5-6, 00 select session(s) for shich DLU is PLU 
01 select session(s) for sthich DLU is SLU 
10 select session(s) regardless of whether DLU is SLU or PLU 
ll reserved 
bit 7, 0 orderly or forced (see byte 4, bit 2) 
1 clean up 
Reason: 
bit 06, 0 network user 
bit 1, 0 normal termination 
1 abnormal termination 
bits 2-7, reserved 
Reserved 
Session key, as described in the section "Session Keys" on page E-23 
Note: One of the following session keys is used: 
X'O01' Uninterpreted name 
X'OA’ URC | 
: This URC is the one carried in the INIT issued previously by the same LU 
(i.e., ILU = TLU), and differs from the one in bytes n+4 through p. 
Retired: set to X‘'0000' 
User Request Correlation (URC) Field 
Length, in binary, of URC field 
Note: X'00° = no URC. 
URC: end-user defined identifier; this value can be returned by the SSCP in a subse- 
quent NOTIFY to correlate the NOTIFY to this terminating request 
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UNBIND 


UNBINDs LU-->LU, Exp; SC (UNBIND SESSION) 


rom. 


UNBIND is sent to deactivate @ scasion betmeen the two LUs. 


X'32' 
Type: 
x'ol' 
X'O02' 


= © 


X'06' 


X'07' 


X'08' 


X'09' 


X'OA' 


X'0B' 


x'0C' 


X'OE' 


X'OF' 


X'11' 


X' FE! 


2-5 Sense 
value 


request code 


normal end of session 

BIND forthcoming: retain the node resources allocated to this session, if pos-~ 
sible 

invalid session parameters: the BIND negotiation has failed due to an inability 
of the primary half-session to support parameters specified by the secondary 
virtual route inoperative: the virtual route used by the LU-LU session has 
become inoperative, thus forcing the deactivation of the identified LU-LU ses- 
Sion 

route extension inoperative: the route extension used by the LU-LU session has 
become inoperative, thus forcing the deactivation of the identified LU-LU ses- 
sion 

hierarchical reset: the identified LU-LU session is being deactivated because 
of a +RSP(CACTPU I ACTLU), Cold) 

SSCP gone: the identified LU-LU session had to be deactivated because of a 
forced deactivation of the SSCP-PU or SSCP-LU session (e.g., DACTPU, DACTLU, or 
DISCONTACT ) 

virtual route deactivated: the identified LU-LU session had to be deactivated 
because of a forced deactivation of the virtual route being used by the LU-LU 
session 

LU failure—unrecoverable: the identified LU-LU session had to be deactivated 
because of an abnormal termination of the PLU or SLU; recovery from the failure 
was not possible 

LU failure—recoverable: the identified LU-LU session had to be deactivated 
because of an abnormal termination of one of the LUs of the session; recovery 
from the failure may be possible 

cleanup: the LU sending UNBIND is resetting its half-session before receiving 
the response from the partner LU 

gateway node cleanup: a gateway node is cleaning up the session because a gate- 
way SSCP has directed the gatenay node (via NOTIFY) to deactivate the session 
(e.g.,» a session setup error or session takedomm failure has occurred) 

format or protocol error: the LU sending UNBIND has detected a format or proto- 
col error; the error is identified by the associated sense data 

data (included only when Type = X'FE's otherwise, this field is omitted): same 
as generated at the time the error was originally detected (e.g., for a negative 


response, receive check, or EXR) 


UNBINDF; PLU-->SSCP, Norm; FMD NS(s) CUNBIND FAILURE ) 


UNBINDF is sent, with no-response requested, by the PLU to notify the 
SSCP that the attempt to deactivate the session between the specified 


LUs has failed (for example, because of a path failure). 


0-2 X'810687' NS header 
3-6 Sense data 
7 Reason: 


bit 0, reserved 


bit 


1, 1 UNBIND error in reaching SLU 


bit 2, 1 takedown reject at PLU 
bits 3-7, reserved 
8-n Session key, as described in the section "Session Keys" on page E-23 


% 


One of the following session keys is used: 


X'07' network address pair: PLU and SLU, respectively 
X'15' network-qualified address pair: PLU and SLU, respectively 
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User Data Subfields 


USER DATA STRUCTURED SUBFIELD FORMATS 


E-16 


neo 


The structured subfields of the User Data field are defined as follows (shown with zero-origin 
indexing of the subfield bytes—see the individual RU description for the actual displacement 
within the RU). Each subfield starts with a one-byte binary Length field and is identified by a 
subfield number in the following byte. The length does not include the Length byte itself. 
When more than one subfield is included, they appear in ascending order by subfield number. 


Any subfields received in the Structured User Data field of BIND that are not recognized by the 
SLU are discarded and not returned as part of the Structured User Data field of the RSP(BIND). 


Unformatted Data Structured Data Subfield 


The Unformatted Data subfield may optionally be sent in BIND or 
RSP(BIND). The content is Reps ent ah OnT cerned: 


lencik of the Poseinder of the Unformatted Data subfield: values 1 to 17 are valid 
X'00' 
-" Unformatted data: a type-G symbol string 


Mode Name Structured Data Subfield 


The Mode Name subfield is present in both BIND and RSP(BIND) if the 


PLU knows the mode name pei used by the session. 


0 Length of the céwai der of the Mode Name Structured User Data subfield: values 1 to 9 


are valid 
1 X'02' 
2-n Mode name: 06 to 8 type-A symbol string characters with optional (but not significant) 


trailing blanks 


Session Instance Identifier Structured Data Subfield 


The Session Tastance Identifier subfield | may Be pieaent in both BIND 


and RSP( BIND). 


6 length of the remainder of the Seuaton instance Identifier subfield: values 3 to 9 


are valid 
h x'03' 
2-n Session instance identifier: a type-6 symbol string 


Note: In BIND, the PLU sets a unique session instance identifier of length 1 to 7 and 
appends it to X'00'. If knomm, the SLU compares its fully qualified name with that of 
the PLU; if the PLU name > SLU name then the SLU changes the first byte of the Session 
Instance Identifier subfield in the BIND response from X'00' to X'F0'3 if the PLU name 
< SLU name then the subfield is simply echoed. The session instance identifier is 
alway present when using either parallel sessions or synchronization level “all.” 


Fully Beer tee PLU Network Name Structured Data Subfield 


BIND enathine the Fully quali fied PLU Network Name subfield Cif the 


name jis Know by the PLU}. 


0 er of the rena indian of the Fully Qualified PLU Network Name subfield: values 2 to 


18 are valid 
1 X'04' 
2-n Fully qualified PLU netnmork name 


Note: The fully qualified PLU network name is 1 to 17 bytes in length, consisting of 
an optional l- to 8&-byte network ID and a 1l- to 8-byte LU name, both of which are 
type-A symbol strings. When present, the network ID is concatenated to the left of 
the LU name, using a separating period and having the form "NWID.NAME'; when the net- 
work ID is omitted, the period is also omitted. 


Fully ane SLU Network Name SRPUCIUr es Data Subfield 


The RSP(BIND) Sbaksins the Fully Qualified SLU Network Name subfield 


Cif the name is known by the SLU). 


0 ieath of the cenainder of the Fully Qualified SLU Network Name subfield: values 2 to 


18 are valid 
I X'O5' 
2-n Fully qualified SLU network name 
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User Data Subfields 


Note: The fully qualified SLU network name is 1 to 17 bytes in length, consisting of 
an optional 1l- to 8-byte network ID and a 1- to 8-byte LU name, both of which are 
type-A symbol strings. When present, the network ID 1s concatenated to the left of 
the LU name, using a separating period and having the form "NWID.NAME"; when the net- 
work ID is omitted, the period is also omitted. 


Random Data Structured Data Subfield 


The Random Data subfield contains the random data used in 
session-level security verification. When session-level security ver- 


ification 1s ineffect, this subfield is present in both BIND and 
RSPCBIND). 


0 Length of the remainder of the Random Data subfield: 10 is the only valid value 

] X'11' 

2 Reserved 

3-10 Random data: a type-G random value generated for subsequent encipherment and checking 


im RSP(BIND) or FMH-12 
Enciphered Data Structured Data Subfield 


The Enciphered Data subfield is present in the RSP(BIND) when 


session-level security verification 1s in effect. This subfield con- 
tains the enciphered version of the random data received in BIND. 


0 Length of the remainder of the Enciphered Data subfield: 9% is the only valid value 
1 X'12' 
2-9 Enciphered version of the Random Data field carried in BIND (using the DES algorithm 


and the installation-defined LU-LU password as the cryptographic key) 
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SUMMARY OF RESPONSE RU'S 


POSITIVE 


E-18 


Apart from the exceptions cited below, response RUs return the number of bytes specified in the 
following table; only enough of the request RU is returned to include the field-formatted 
request code. | 


RU Category of Response Number of Bytes in RU 
sc 1 
DFC l 
FMD NS (FI=1) (field-formatted) 3 
FMD NS (FI=0) (character-coded) 0 
FMD (LU-LU) 0 


Various positive response RUs return additional data. See "Positive Response RU's with Extended 
Formats" for details. 


All negative responses return four bytes of sense data in the RU, followed by either (1) the 
number of bytes specified in the table above or (2) three bytes (or the entire request RU, if 
shorter than three bytes). The second option applies where a sensitivity to SSCP-based sessions 
versus LU-LU sessions does not exist and can be chosen for implementation simplicity. Refer to 
"Appendix G. Sense Data" for sense data values and their corresponding meanings. 


RESPONSE RU'S WITH EXTENDED FORMATS 


SRTERINRES «cine aeeTeviytorvinad: «FR ARRCWAINEDAmiaMaiaiedTisinizennnE «oS RSet AEN 


RSPCACTLU)$; LU-->SSCP, Exp; SC 


0 X'OD' request code 

1 Type of activation selected: 
X'O01' cold 
X'O2°' ERP 

2 bits 0-3, FM profile: 


X'O' FM Profile 0 
X'6' FM Profile 6 
Note: This field contains the same value as the FM profile field received 
in the ACTLU request except in the following case. If the request specified 
FM profile 0, the LU may respond either FM profile 0 or FM profile 6. 
bits 4-7, TS profile: same as the corresponding request 
3-m Control vectors, as described in the section "Control Vectors" on page E-20 


Note: Two versions of this RU are defined. 


¢ A full response can be sent in which all fields and control vectors are present. These con- 
trol vectors always appear in the following order: 


X'00' SSCP-LU session capabilities 
X'OC' LU-LU session services capabilities 


e A two-byte response can be sent; it means maximum Pl’ size = 256 5,423, LU-LU session limit = 
1, the LU can act as a secondary LU, and all other fields in control vectors X'00' and xX'0C' 


are defaulted to 0's. 
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RSPC BIND ) 


RSP(BIND); SLU-->PLU, Exp; SC 
0 X'31' request code 
1 bits 0-3, format: 0000 
bits 4-7, type: 
0000 negotiable 
2-25 Bytes as received on BIND request, or bytes having the same format as, but possibly 
with values changed from, those received on the BIND request 
26-K Cryptography Options 
26 bits 0-1, reserved 
bits 2-3, session-level cryptography options: same value returned as received in the 
request 
bits 4-7, session-level cryptography options field length: same value returned as 
received in the request (Bytes 27-k are omitted if this length field is 
omitted or set to 0.) 
27 bits 0-1, session cryptography key encipherment method: same value returned as 
received in the request, if present 
bits 2-4, reserved 
bits 5-7, cryptography cipher method: same value returned as received in the request, 
1f present 


28-k An eight-byte implementation-chosen, nonzero, pseudo random session-seed cryptography 
value enciphered under the session cryptography key, if session-level cryptography is 
speci fied 

k+i-r Bytes as received on BIND request, or bytes having the same format as, but possibly 


with values changed from, those received on the BIND request 
Note l: The extended format is required for the BIND response. 


Note 2: On a response, if the last byte of a response is a Length field and that field is 0; 
that byte may be omitted from the response. This applies also to byte 26 (where the count occu- 
pies only bits 4-7) if bits 0-3 are also 0—the entire byte may be omitted if no bytes follow. 


Note 3: Reserved fields in the BIND are set by the SLU to binary 0's in the RSP(BIND); any 
fields at the end of the BIND that are not recognized by the SLU are discarded and not returned 
in the RSP(BIND). 


RSP(CINIT); PLU-->SSCP, Norms; FMD NS(s) 

0-2 X'810601' NS header 

3-n Control vectors as described in the section "Control Vectors" on page E-20 
Note: The following control vector key 1s used in RSP(CINIT): 
X'FE' control vector keys not recognized 
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Control: Vectors 


COMMON STRUCTURED SUBFIELDS 


E~-20 


CONTROL VECTORS 


The following table shows, by key value, the control vector and the message-unit structures that 
can carry the control vector. 


Key Control Vector Applicable Message-Unit Structures 

X'00' SSCP-LU Session Capabilities . RSPCACTLU) 

X'OC' LU Session Services Capabilities RSP(ACTLU) 

X'OD' Mode / Class-of-Service / CINIT 
Virtual-Route-Identifier-List 

X'15' Network-Qualified Address Pair CINIT 

X'1E' VR-ER Mapping Data SESSST 

X'23' Local-Form Session Identifier SESSST 

X'FE' Control Vector Keys Not RSP(CINIT) 
Recognized 


Note: Control vector X'FE' is used to report receipt of one or more unrecognized control vec- 
tors, provided that each unrecognized control vector has a key greater thatn X'08'. <A negative 
response indicating sense code 0835—Invalid Parameter (with Pointer Only)—is returned if a 
request 1s received with an unrecognized control vector with a key less than or equal to X'08'. 
When all unrecognized control vectors have keys greater than 8, the receiver responds using a 
X'FE' control vector that identifies each unrecognized control vector by key; this allows the 
response sender to indicate that some control vectors have been processed, while others have 
not. 


The control vectors are defined as follows (with zero-origin indexing of the vector bytes—see 
the individual RU description for the actual displacement within the RU): 

Note: When more than one control vector may appear in an RU, the vectors may appear in any 
order, unless otherwise stated. 


SSCP-LU Session Capabilities Control Vector 


0 Key: xX'00' 

1 Maximum RU size sent on the normal flow by either half-session: if bit 0 is set to 0; 
then no maximum is specified and the remaining bits 1-7 are ignored; if bit 0 is set 
to 1, then the byte is interpreted as X'ab' = a®2%*b. (Notice that, by definition; 


a28 and therefore X'ab' is a normalized floating point representation.) See Fig- 
ure E-l on page E-8 for all possible values. 

2-3 LU capabilities: 
bit 0, character-coded capability: 

0 the SSCP may not send unsolicited character-coded requests; a solicited 
request is a reply request or a request that carries additional error infor- 
mation to supplement a previously sent negative response or error informa- 
tion after a positive response has already heen sent 

1 the SSCP may send unsolicited character-coded requests 

bit 1, field-formatted capability: | 

0 the SSCP may not send unsolicited field-formatted requests 

1 the SSCP may send unsolicited field-formatted requests 

bits 2-15, reserved 
4 Reserved 
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Control Vectors 


LU-LU Session Services Capabilities Control Vector 


2-m 


8-15(=m) 


Key: X'OC' 
Length, in binary, of Vector Data field 
Vector Data 
bits 0-3, primary LU capability: 
0000 PLU capability ts inhibited, sessions can neither be queued nor started 
0001 PLU capability is disabled, sessions can be queued but not started 
0010 reserved 
0011 PLU capability is enabled, sessions can be queued or started 
bits 4-7, secondary LU capability: 
0000 SLU capability is inhibited, sessions can neither be queued nor started 
0001 SLU capability is disabled, sessions can be queued but not started 
0010 reserved 
0011 SLU capability is enabled, sessions can be queued or started 
LU-LU session limit (where a value of 0 means that no session limit is specified) 
LU-LU session count: the number of LU-LU sessions that are not reset, for this LU; 
and for which SESSEND will be sent to the SSCP 
bit 0, parallel session capability: 
0 parallel sessions not supported 
1 parallel sessions. supported 
bit 1,5 reserved 
bit 2, SESSST capability in RSP(ACTLU) (reserved in NOTIFY): 
0 SESSST RU is suppressed if SLU 
1 SESSST RU is sent if SLU 
bits 3-7, reserved 
Retired (set to X'4040404040404040') or omitted 


Mode/ Class-of-Service/ Virtual-Route-Identifier-List Control Vector 


20 


21 
2e-n 


Key: xX'OD' 

Length, in binary, of Vector Data field 

Vector Data 

Mode name: an eight-character symbolic name (implementation and installation depend- 

ent) of type-A symbol string characters that identifies the set of rules and protocols 

to be used for the session; used by the SSCP(SLU) to select the BIND image that is to 

be used by the SSCP(PLU) to build the CINIT request 

COS name: symbolic name of class of service in EBCDIC characters 

Virtual Route Information 

Length (in bytes)—binary, not including this length field, of remainder of Virtual 

Route Information field 

Format of virtual route identifier list: 

X'00' format 0 

Type of virtual route required: 

X'00' only virtual routes mapping to ERO from the subarea of the SLU to the subarea of 
the PLU may be used 

X'O1l' virtual routes mapping to any ERN may be used 

Number of entries in the virtual route identifier list 

Virtual route identifier list: two-byte (VRN, TPF) entries where VRN is one byte and 

TPF is one byte 


Network-Qualified Address Pair Control Vector 


0 
1 
e-n 
2-7 
8-13 


14-210=n) 


Key: X'15' 

Length, in binary, of Vector Data field 

Vector Data 

NAU 1 network address 

NAU 2 network address 

Note: See the RUs that carry this vector for NAUI/NAU2 definitions and order require- 
ments. 

Network ID of the subnetwork in which the above addresses are valid 

Note: If the Network ID contains all space (X'40...40') characters, the network 
addresses are in the sender's network. 
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Control Vectors 


VR-ER Mapping Data Control Vector 
0 Key: X'IE' 
| Length, in binary, of Vector Data field 
2-n Vector Data | ee 
2 VRN and TPF data: | 
bits 0-3, virtual route number (VRN) used by the session indicated in the containing 
RU 7 
bits 4-5, reserved | 
bits 6-7, Transmission Priority field (TPF) used by the session indicated in the con- 
taining RU 
3 Explicit route data: 
| bits 0-3, reserved | 
bits 4-7, outbound ERN for the VRN specified in byte 2, bits 0-3 
G(=n) Reverse explicit route data: 
bits 0-3, reserved | 
bits 4-7, RERN corresponding to the VRN specified in byte 2, bits 0-3 


Local Form Session Identifier Control Vector 


0 Key: X'23°' 

1 Length, in binary, of Vector Data field 
2-p Vector Data 

2 Format: 


X'O02' Format 2: FID 2 format session identifier 
X'O3" Format 3: FID 3 format session identifier 


® For format 2—FID 2 


3-p Session identifier for Format 2—-FID 2 
3 OAF' from the TH of the BIND request 

& DAF’ from the TH of the BIND request 
5(=p) Flags: 


bits 0-5, reserved 
bit 6, ODAI field from TH of the BIND request 
bit 7, reserved 


® For format 3--FID 3 


3-p Session identifier for Format 3-—FID 3 

3(=p) LSID from TH of the BIND request 

Control Vector Keys Not Recognized Control Vector 

0 Key: X'FE' 

1 Length, in binary, of Vector Data field 

2-r Vector data: one or more one-byte control vector key values that were not recognized 


in the corresponding request 
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SESSION K 


Session Keys 


EYS 


The following table shows, by key value, the session key and the message-unit structures that 


can carry the session Key. 

Key Session Key Applicable Message-Unit Structures 

X'O1' Uninterpreted name 7 TERM-SELF 

X'06' Network name pair NOTIFY 

X'07° Network address pair BINDF, CINIT, CLEANUP, CTERM, NOTIFY, SESSEND, SESSST, 
UNBINDF 

X'OA' URC NOTIFY, TERN-SELF 


X'15' Network-Qualified address pair BINOF, CLEANUP, CTERM, NOTIFY, SESSEND, SESSST, UNBINDF 


The session keys are defined as follows (mith zero-origin indexing of the key bytes—see the 


indi vidua 


1 RU description for the actual displacement within the RU). 


Uninterpreted Name Session Key 


0 
1 
2 
3-n 


Key: xX'Ol' 

Type: X'F3' logical unit 

Length, in binary, of name 

Uninterpreted Name 

Note: The name is an EBCDIC character string. 


Network Name Pair Session Key 


0 

1 

2 

3-m 
wil 
wmt2 
mt3-n 


Key: X'06' 

Type: X'F3' logical unit 

Length, in binary, of PLU (or OLU or LU1]) name 
Name in EBCDIC characters (see Note below) 
Type: X'F3' logical unit 

Length, in binary, of SLU Cor DLU or LU2) name 
Name in EBCDIC characters (see Note below) 


Note: The names in this session key consist of type-A symbol string characters. 


Network A 
0 


1-2 
3-4 


ddress Pair Session Key 

Key: X'07' 

Network address of NAUI 

Network address of NAU2 

Note: See the RUs that carry this session key for NAUI/NAU2 definitions and order 
requirements. 


URC Session Key 


0 
1 
2-n 


Key: X‘QA' 
Length, in binary, of the URC 
URC: LU-defined identifier 


Network-Qualified Address Pair Session Key 


0 

1 
2-21 
e-7 
8-13 


14-21 


Key: X°15' 

Length, in binary, of Key Data field 

KEY Data field 

NAUI network address 

NAU2 network address 

Note: See the RUs that carry this session key for NAUI/NAU2 definitions and order 
requirements. 

Network ID of the subnetwork in which the above addresses are valid 

Note: The Length byte is set to 12 when network ID is not included and to 20 when 
network ID is included. If the Network ID contains all space (X'40...40') characters, 
the network addresses are in the sender's network. 
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Common Subvectors 


E-24 


COMMON SUBVECTORS 


The following table shows, by key value, the common subvectors and the message-unit structures 
that can carry the subvector. 


Key Subvector Applicable Message Unit 
X'10' Product Set ID Error Log GOS variable 
X'11' Product ID Error Log 6DS variable 


The common subvectors are defined as follows (with zero-origin indexing of the vector bytes—see 
the applicable message unit for the actual displacement within the message unit): 


Product Set ID (X'10') Common Subvector 


The Product Set ID subvector is an MS common subvector identifying one 
| or more products that implement a network component. 


0 Length (p+l), in binary, of the Product Set ID subvector 

| Key: xX"'10' 

2 Retired 

3-p Network product identifier consisting of one or more Product ID (X'11') MS common sub- 


vectors, as described below (using zero-origin indexing). Each Product ID ¢X'11") MS 
Common Subvector uniquely identifies a product. Products fall into two categories: 
hardware (with or without microcode) and softmare. 


Product Identifier (X'11'"} Common Subvector 


The Procuct Identifier MS common subvector uniquely identifies a prod- 
uct. A product may consist of electronic circuitry (hardware), exe- 


cutable instructions (softnare), or both (Cin the case of hardware 
containing microcode). 


Length (q+1), in binary, of the Product Identifier subvector 


0 
| Key: xX'IL' 
2 bits 0-3, Reserved 
bits 4-7, Product classification: 
X'L' IBM hardware 
X'3' IBM or non-IBM hardware (not distinguished) 
X'4' IBM software 
X'9' non-IBM hardware 
X'C' non-IBM software 
X'E' IBM or non-IBM software (not distinguished) 
3-q One or more subfields containing product- and installation-specific information on 
hardware, microcode, and software (listed by Key value below and described in detail | 
following): 


X'00' Hardware Product Identifier 

X'O1L' Emulated Hardware Product Identifier 

X'02' Software Product Serviceable Component Identifier 
X'03' Retired 

X'04' Software Product Common Level 

X'05' Retired 

X'06' Software Product Common Name 

X'07' Software Product Customization Identifier 

X'08' Software Product Program Number 

X'09' Software Product Customization Date and Time 


Harduare Product Identifier (X'00') Product Identifier Subfield 


0 Length (rl); in binary: of the Hardware Product Identifier subfield 
1 Key: X'00' 
2 Format type: 


X'10' product instance is identified by a serial number (i.e., IBM plant of manufac- 
ture and sequence number) unique by machine type | | 
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Common Subvectors 


X'1l' product instance is identified by a serial number (i.e., IBM plant of manufac- 
ture and sequence number) unique by machine type and model number 

X'12" product instance is identified by a serial number (i.e., IBM plant of manufac-~- 
ture and sequence number) unique by machine type (as in Format X'10' above). 
This format provides the model number not to uniquely identify a product 
instance but, for the purpose of additional information only. 

X'13' retired 

X'40' retired 

X'41" retired 


3-r Product identification 
Note: The originator of a message unit fe.g., NMVT, XID) reporting for another prod- 
uct that does not supply information required for the Hardware Product Identifier sub- 
field inserts binary 0's into the appropriate fields (except for the Machine Type 
field where EBCDIC 0's [X'FO0'] are inserted) of the Product Identification field to 
indicate that no identification information is available. 


® Format X'10' 

3-6 Machine type: four numeric EBCDIC characters 

7-8 IBM plant of manufacture: two numeric EBCDIC characters 

9-15(=r) Sequence number: seven upper-case alphanumeric EBCDIC characters, right-justified, 
with EBCDIC O's (X'FO') fill on the left 


® Format X'1l' 


3-6 Machine type: four numeric EBCDIC characters 
7-9 Machine model number: three upper-case alphanumeric EBCDIC characters 
10-11 IBM plant of manufacture: two numeric EBCDIC characters 


12-18(=r) Sequence number: seven upper-case alphanumeric EBCDIC characters, right-justified, 
with EBCDIC O's (X'FO') fill on the left 


© Format X'1l2' 


3-6 Machine type: four numeric EBCDIC characters 
7-9 Machine model number: three upper-case alphanumeric EBCDIC characters 
10-11 IBM plant of manufacture: two numeric EBCDIC characters 


12-18(=r) Sequence number: seven upper-case alphanumeric EBCDIC characters, right-justified, 
with EBCDIC O's (X'FO') fill on the left 


Emulated Product Identifier (X'01') Product Identifier Subfield 


This subfield describes the hardware of the product being emulated in 


sufficient detail to allon problem determination 


Length (r+1), in binary, of the Emulated Product Identifier subfield 
Key: xX'Ol' 
Machine type of product being emulated: four numeric EBCDIC characters 
(=r) Model number of product being emulated: three upper-case alphanumeric EBCDIC charac- 
ters 


Software Product Serv ieerkae Component Identifier (X°02') Product Ident) fier Siler? 


This nibfield provides the Paces canble eumeonent identifier sind 


release level as nsctgned by service personnel. 


0 Length (rel), in binary: of the Sat tuare Product Secvceabla oapenent Identifier sub~ 


field 
1 Key: xX'O02' 
2-10 Serviceable component identifier: nine upper-case alphanumeric EBCDIC characters 


11-13(=r) Serviceable component release level: three numeric EBCDIC characters 


Software Product Common Level (X'04') Product identi nver Subtield 


This subfield provides the common version, selease: and modification 


level ees as given in the prowset BEEN ene documentation. 


0 tength (rel); in binary» of the Softnare Product Caeat bevel subfield 
1 Key: X'04' 
2 


~3 Common version identifier (numeric EBCDIC characters, right-justified mith X'FO' Fill 
on left) 

4-5 Common release identifier (Crameric EBCDIC characters, right-justified with X'FO' fill 
on left) 
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6-7(=r) 


Common modification identifier (numeric EBCDIC characters, right-justified with X'FO' 
fill on left) 


Software Product Common Name (X'06') Product anions Subfield 


Me © 


This subfield provides the common name as given in” the product 
announcement documentation 


Length (r+l), in binary, of the Software Product Common Name subfield 

Key: X‘'06' 

Up to thirty upper-case alphanumeric EBCDIC characters identifying the product common 
name 


Software Product Customization Identifier (X%'07') Product Identifier Subfield 


N & © 


This subfield identifies a set of executable instructions, customized 
to the user's environment 


€ 
s 
ee 
cy 
e 
€ 
e 
€ 
e 
i 


Length (r+1), in binary, of the Software Product Customization Identifier subfield 
Key: X'07' 
Customization identifier: up to eight alphanumeric EBCDIC characters 


Software Product Program Number (X'08') Product Identifier Subfield 


N = & 


This subfield provides the program product number as assigned by dis- 
tribution personnel 


« s 
® 
3 
€ 
e 
¢ 
® 


Length (r+1), in binary, of the Software Product Program Number subfield 
Key: X'08' 
Program product number: seven upper-case alphanumeric EBCDIC characters 


Software Product Customization Date and Time (X'09') Product Identifier Subfield 


This subfield identifies the date and time that a set of executable 


instructions was customized to the user's environment 


Length (r+1), in binary, of the Software Product Customization Date and Time subfield. 
Key: X'09' 

Year in uns igned packed decimal 

Julian day in unsigned packed decimal, right-justified with 0's as fill 

Hour tn unsigned packed decimal (24-hour clock) 

Minute in unsigned packed decimal 
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APPENDIX F. PROFILES 


FUNCTION MANAGEMENT (CFM) PROFILES 


This section describes the function management (FM) profiles and their use for LU 6.2 sessions. 
Profile numbers not shown are reserved in these sessions. 


Note: If the FM Usage field in BIND specifies a value for a parameter, that value is used 


unless it conflicts with a value specified by the FM profile. The FM profile overrides the FM 
Usage field. 


FM PROFILE 0 


Profile 0 (used on SSCP-LU sessions) specifies the following session rules: 
Primary and secondary half-sessions use immediate request mode and immediate response mode. 
Only single-RU chains allowed. 
Primary and secondary half-session chains indicate definite response. 
No compression. 
Primary half-session sends no DFC RUs. 
Secondary LU half-session may send LUSTAT. 
No brackets. 
No FM headers. 
No alternate code. 


Normal-flow send/receive mode is full-duplex. 
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FM PROFILE 6 


Profile 6 (used on SSCP-LU sessions) specifies the following session rules: 
Primary and secondary half-sessions use delayed request mode and delayed response mode. 
Only single-RU chains allowed. 


Primary and secondary half-session chains may indicate definite response, exception 
response, or no response. 


No compression. 

Primary half-session sends no DFC RUs. 
Secondary half-session may send LUSTAT. 
No brackets. 

No FM headers. 

No alternate code. 


Normal-flow send/receive mode is full-duplex. 
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FM PROFILE 19 


Profile 19 (used on LU-LU sessions) specifies the following session rules: 


Primary LU half-session and secondary LU half-session use immediate request and immediate 
response mode. 


Multiple RU chains allowed. 


Primary LU half-session and secondary LU half-session chains indicate definite or exception 
response. 


No compression. 


Primary and secondary half-sessions support the following DFC functions: 
SIGNAL 
LUSTAT 
BIS 
RTR 
Brackets are used. 


rM headers (types 5 and 7 only) are allowed. 


Conditional termination for brackets (specified by CEB) will be used--primary and secondary 
half-sessions may send CEB. 


The following combinations of RQE, RQD, CEB, and CD are allowed on end-chain RUs: 
RQEX, CD, -~CEB 
RQD2, CD, ~CEB 
RQD3, CD, -CEB 
RQE1, -CD, CEB 
RQD*, -CD, CEB 
RQD*, -CD, -CEB 
Normal-flow send/receive mode is half-duplex flip-flop. 


Half-duplex flip-flop reset state is send for the primary LU half-session and receive for 
the secondary LU half-session after RSP(BIND). 


Symmetric responsibility for recovery. 


Contention winner/loser polarity is negotiated at BIND times the contention winner ts the 
first speaker and the contention loser is the bidder. 


The only FM Usage field defining options for Profile 19 is Contention Winner/Loser. 
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FM PROFILE VS. TYPE OF SESSION 
The following table specifies which FM profiles may be used with each type of session. 


Type of Session 


SSCP-LU LU-LU 


FM Profile 


LUs in the same node as an SSCP use FM profile 6 
for the SSCP-LU session; otherwise, the LU uses FM profile 0. 
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ANSMISSION SERVICES (TS) PROFILES 


This section describes the transmission services (TS) profiles and their use for LU 6.2 ses- 
Sions. Profile numbers not shown are reserved in these sessions. 


Note: If the TS Usage field in BIND specifies a value for a parameter, that value is used 


unless it conflicts with a value specified by the TS profile. The TS profile overrides the TS 
Usage field. 


TS PROFILE 1 


Profile 1 (used on SSCP-LU sessions) specifies the following session rules: 
No pacing. 
Identifiers rather than sequence numbers are used on the normal flows. 
SDT, CLEAR, RAR, STSN; and CRV are not supported. 


Maximum RU size on the normal flow fer either half-session is 256, unless a different value 
is specified in RSPCACTLU). 


There is no Ts usage field associated with this profile. 
TS PROFILE 7 


Profile 7 (used on LU-LU sessions) specifies the following session rules: 
Primary-to-secondary and secondary-to-primary normal flows are optionally paced. 
Sequence numbers are used on the normal flows. 

SDT, CLEAR, RQR, and STSN are not supported. 
CRV is supported when session-level cryptography 1s selected (via a BIND parameter). 

The TS Usage subfields in BIND defining the options for this profile are: 

Pacing counts 


Maximum RU sizes on the normal flows 
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TS PROFILE VS. TYPE OF SESSION 


The following table specifies which TS profile may be used with each type of session. 


Type of Session | 
TS Profile SSCP-LU LU-LU 


1 yes no 
7 no . yes 
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APPENDIX G. SENSE DATA 


The sense data included with an EXCEPTION REQUEST (EXR), a negative response, an UNBIND request, 
a function management header type 7 (FMH-7), or a send or receive check is a four-byte field 
(see Figure 6-1) that generally includes a one-byte category value, a one-byte modifier value, 
and two bytes of sense code specific information, whose format is defined along with the sense 
code definition, below. 


Byte 0 1 2 3 


Category | Modifier Sense code specific 
information 


Sense Code 


' 
>| 
| 


(——————————_—_—_—- Sanse Data ———————___—————> 


Figure 6-1. Sense Data Format 


Together, the category byte 0, the modifier byte 1, and the sense code specific bytes 2 and 3 
hold the sense data defined for the exception condition that has occurred. 


The following categories are defined; all others are reserved: 


VALUE CATEGORY 

X'00' User Sense Data Only 

X't8' Request Reject 

Xx'10' Request Error 

X'20' State Error 

X'40' Request Header (RH) Usage Error 
xX'80' Path Error 


The category User Sense Data Only (X'00') allows the end users to exchange sense data in bytes 
2-3 for conditions not defined by SNA within the other categories (and perhaps unique to the end 
users involved). The modifier value is also X'00'. In earlier versions of SNA, user data (as 
well as implementation-specific data) generally could be carried in bytes 2-3 for all catego- 
ries. This is no longer permitted. Bytes 2-3 are used only for SNA-defined conditions for non- 
zero categories. 


The sense codes for the other categories are discussed below. 
EQUEST REJECT (CATEGORY CODE = X'08') 


This category indicates that the request was delivered to the intended half-session component 
and was understood and supported, but not executed. 


Category and modifier Cin hexadecimal ): 


0801 Resource Not Available: The LU, PU, or link specified in an RU is not available. 
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G-2 


6805 


0806 
0809 


O80A 


O80E 


O80F 


0812 


0813 
0814 


0815 
0816 


0819 
081A 


0820 


0823 


0824 


Session Limit Exceeded: The requested session cannot be activated, as one of the NAUs 
is at its session limit (e.g., LU-LU session limit, or [LU, mode] session limit). 
Applies to ACTCDRM, INIT, BIND, and CINIT requests. 


Bytes 2 and 3 may contain the following sense code specific information: 


0000 No specific cede applies. 


0001 If accepted, the BIND request would prevent either the receiving LU or the send- 
ing LU from activating the number of contention winmer sessions to the partner 
LU that were agreed upon during a change-number-of-sessions procedure. 


Resource Unknown: The request contained a name or address not identifying a PU, LU, 
links or link station Known to the receiver. 


Mode Inconsistency: The requested function cannot be performed in the present state 
of the receiver. 


Permission Rejected: The receiver has denied an implicit or explicit request of the 
sender; when sent in response to BIND, it implies either that the secondary LU will 
not notify the SSCP when a BIND can be accepted, or that the SSCP does not recognize 
the NOTIFY vector key X'0C'. (See the X'0845' sense code for a contrasting response. ) 


NAU Not Authorized: The requesting NAU does not have access to the requested 
resource. 


End User Not Authorized: The requesting end user does not have access to the 
requested resource. 


Bytes 2 and 3 may contain the following sense code specific information: 

0000 No specific code applies. 

6051 Security Violation: A security protocol error has been detected in an RU 
received from the remote LU or transaction program. This sense data is sent in 


~RSP(BIND}, UNBIND, and FMH-7. 


Insufficient Resource: Receiver cannot act on the request because of a temporary lack 
of resources. 


Bracket Bid Reject--No RTR Forthcoming: BID (or BB) was received mhile the first 


speaker was in the in-bracket state, or while the first speaker was itn the 
between-brackets state and the first speaker denied permission. RTR will not be sent. 


Bracket Bid Reject--RTR Forthcoming: BID (or BB) was received while the first speaker 
was in the in-bracket state, or while the first speaker was in the between-brackets 
state and the first speaker denied permission. RTR will be sent. 


Function Active: A request to activate a network element or procedure was received; 
but the element or procedure was already active. 


Function Inactive: A request to deactivate a network element or procedure was 
received, but the element or procedure mwas not active. 


RTR Not Required: Receiver of READY TO RECEIVE has nothing to send. 
Request Sequence Error: Invalid sequence of requests. 


Control Vector Error: Invalid data for the control vector specified by the target net- 
work address and key. 


Unknoem Control Vector: The control vector specified by a network address and key is 
not Known to the receiver. 


Logical Unit of Work Aborted: The current unit of work has been aborted; when sync 
point protocols are in use, both sync point managers are to revert to the previously 
committed sync point. 


Bytes 2 and 3 may contain the following sense code specific information: 


0000 For LU 6.2, Backout Initiated: A transaction program or its LU has initiated 
backout. The protected resources for the distributed logical unit of work are 
to be restored to the previously committed sync point. This sense data is sent 
only in FMH-7. 
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082eC 


0835 


0836 


0837 


0839 


083A 


0842 


0845 


0846 


0848 


084B 


084C 


For non-LU 6.2) no specific code applies. 


Resource-Sharing Limit Reached: The request received from an SSCP was to activate a 
half-session, a link, or a procedure, when that resource was at its share limit. 


Invalid Parameter (with Pointer Only): The request contained aie fixed- or 
variable-length field whose contents are invalid or not supported by the NAU that 
received the request. Bytes 2 and 3 are used for sense code specific information: 


nnnn Bytes 2 and 3 contain a two-byte binary count that indexes (zero-origin) the 
first byte of the fixed- or variable-length field having invalid contents. 


PLU/SLU Specification Mismatch: For a specified LU-LU session, both the origin LU 
(OLU) and the destination LU (DLU) have only the primary capability or have only the 
secondary capability. 


Queuing Limit Exceeded: For an LU-LU session initiation request (INIT, CDINIT, or 
INIT-OTHER-CD) specifying (1) Initiate or Queue (if Initiate not possible) or (2) 
Queue Only, the queuing limit of either the OLU or the DLU, or both, was exceeded. 


LU-LU or SSCP-LU Session Being Taken Down: At the time an LU-LU session initiation or 
termination request is received, the SSCP of at least one of the LUs is either proc- 
essing a CDTAKED request or is in the process of deactivating the assoctated SSCP-LU 
Session. 


LU Not Enabled: At the time an LU-LU session initiation request is received at the 
SSCP, at least one of the two LUs, although paying an active session with its SSCP, is 
not ready to accept CINIT or BIND requests. 


SSCP-SSCP Session Not Active: The SSCP-SSCP session, which is required for the proc- 
essing of a network services request, is not active; e.g., at the time an LU-LU ses- 
Sion initiation or termination request is received, at least one of the following 
conditions exists: 


° The SSCP of the ILU and the SSCP of the OLU do not have an active session with 
each other, and therefore INIT-OTHER-CD cannot flow. 


e The SSCP of the OLU and the SSCP of the DLU do not have an active session with 
each other, and therefore CDINIT or CDTERM cannot flow. 


Permission Rejected--SSCP Will Be Notified: The receiver has denied an implicit or 
explicit request of the sender; when sent in response to BIND, it implies that the 
secondary LU will notify the SSCP (via NOTIFY vector key X'0C') when a BIND can be 
accepted, and the SSCP of the SLU supports the notification. (See the X'080A' sense 
code for a contrasting response. ) 


ERP Message Forthcoming: The received request was rejected for a reason to be speci- 
fied in a forthcoming request. 


Cryptography Function Inoperative: The receiver of a request was not able to decipher 
the request because of a malfunction in its cryptography facility. 


Requested Resources Not Available: Resources named in the request, and required to 
honor it, are not currently available. It is not Known when the resources will be 
made available. 


Bytes 2 and 3 may contain the following sense code specific information: 

0000 No specific code applies. 

6031 Transaction Program Not Available--Retry Allowed: The FMH-5 Attach command 
specifies a transaction program that the receiver is unable to start. Either 
the program is not authorized to run or the resources to run it are not avail- 


able at this time. The condition is temporary. The sender is responsible for 
subsequent retry. This sense data is sent only in FMH-7. 


Permanent Insufficient Resource: Receiver cannot act on the request because resources 
required to honor the request are permanently unavailable. The sender should not 
retry immediately because the situation is not transient. 

Bytes 2 and 3 may contain the following sense code specific information: 

0000 For LU 6.2, Transaction Program Not Available -- No Retry: The FMH-5 Attach 


command specifies a transaction program that the receiver is unable to start. 
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084D 


O84E 


0852 


0856 


0857 


0859 


0861 


0864 


The condition is not temporary. The sender should not retry immediately. This 
sense data is sent only in FMH-7. 


For non-LU 6.25 no additional information is specified. 


Invalid Session Parameters--BF: Session parameters were not valid or were unaccepta- 
ble by the boundary function. Bytes 2 and 3 following the sense code contain a binary 
count that indexes (zero origin) the first byte of the fixed- or variable-length field 
having invalid contents. 


Invalid Session Parameters--PRI: A positive response to an activation request (e.g., 
BIND) was received and was changed to a negative response because of invalid session 
parameters carried in the response. The services manager receiving the response will 
send a deactivation request for the corresponding session. 


Duplicative Session Activation Request: Two session activation requests have been 
received with related identifiers. The relationship of the identifiers and the 
resultant action varies by request. For BIND, it means that the BIND request was 
received with the same session instance identifier (Cin the structured subfield X'03' 
of the User Data field) as an active session's; the current request is refused. 


SSCP-SSCP Session Lost: Carried in the Sense Data field itn a NOTIFY (Third-Party 
Notification vector, X'03') or -RSPC(INIT_OTHER) sent to an ILU to indicate that the 
activation of the LU-LU session is uncertain because the SSCP(ILU)-SSCP(OLU) session 
has been lost. (Another sense code, X'0842', is used when it is Known that the LU-LU 
session activation cannot be completed. ) 


SSCP-LU Session Not Active: The SSCP-LU session, required for the processing of a 
request, is not active; e.g.» in processing REQECHO, the SSCP did not have an active 
session with the target LU named in the REQECHO RU. 


REQECHO Data Length Error: The specified length of data to be echoed (in REQECHO) vio- 
lates the maximum RU size limit for the target LU. 


Invalid COS Name: The class of service (COS) name, either specified by the ILU or 
generated by the SSCP of the SLU from the mode table is not in the "COS name to VR 
identifier list" table used by the SSCP of the PLU. 


Bytes 2 and 3 may contain the following sense code specific information: 
0000 COS name was generated by the SSCP. 
0001 COS name was generated by the ILU. 


0003 CDINIT request (or response) contains a Session Initiation control vector that 
has class of service (COS) name fields that have not been properly specified. 
If the RU is a positive response, it is changed into a negative response and 
sent to the request sender; a CDTERM is sent to the CDINIT response sender. 
(This 1s to cover a system definition error in the event a gateway SSCP down~ 
stream from another gateway SSCP receives a CDINIT or RSP(CDINIT) without valid 
information in the appropriate COS name fields of the Session Initiation control 
vector. ) 


Function Abort: The conversation was terminated abnormally. Other terminations may 
occur after repeated reexecutions; the request sender is responsible to detect such a 
loop. 


Bytes 2 and 3 may contain the following sense code specific information: 


0000 For LU 6.2, Premature Conversation Termination: The conversation is terminated 
abnormally; for example, the transaction program may have issued a DEALLO- 
CATE_ABEND verb, or the program may have terminated (normally or abnormally) 
without explicitly terminating the conversation. This sense data is sent only 
in FMH-7. 


For non-LU 6.2, no additional information is specified. 


0001 System Logic Error--No Retry: <A system logic error has been detected. No retry 
of the conversation should be attempted. This sense data is sent only in FMH-7. 


0002 Excessive Elapsed Time--No Retry: Excessive time has elapsed while waiting for 
a required action or event. For example, a transaction program has failed to 
issue a conversation-related protocol boundary verb. No retry of the conversa- 
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0889 


088B 


08é6C 


tion should be attempted. This sense data is sent itn UNBIND when there ts no 
chain to respond to; otherwise, it is sent in FMH-7. 


Transaction Program Error: The transaction program has detected an error. 
This sense code is sent only in FMH-7. 
Bytes 2 and 3 may contain the following sense code specific information: 


0000 Program Error--No Data Truncation: The transaction program sending data 
detected an error but did not truncate a logical record. 


Program Error--Purging: The transaction program receiving data detected an 
error. All remaining information, if any, that the receiving program had not 
yet received, and that the sending program had sent prior to being notified of 
the error, is discarded. 


0001 Program Error--Data Truncation: The transaction program sending data detected 
an error and truncated the logical record it was sending. 


0100 Service Error--No Data Truncation: The presentation services component for 
mapped conversations detected an error shile sending data but did not truncate a 
logical record. 


Service Error--Purging: The presentation services component for mapped conver- 
sations detected an error while receiving data. All remaining information, if 
any, that the receiving mapped-conversations component had not yet received, and 
that the sending component had sent prior to being notified of the error, is 
discarded. 


0101 Service Error--Data Truncation: The presentation services component for mapped 
conversations detected an error while sending data and truncated the logical 
record it mwas sending. 


BB Not Accepted--BIS Reply Requested: Sent in response to a BB (either an LUSTAT bid 
or an Attach) to indicate that the receiver has sent a BIS request and wishes to ter- 
minate the session without processing any more conversations, but without sending an 
UNBIND. A BIS reply is requested so that the negative response sender may send a 
normal | UNBIND. This sense code is sent only by Us not = supporting 
change-number-of-session protocols. 


Missing Control Vector: The RU did not contain a control vector which was expected to 
appear. The first byte of the sense code specific field contains the hex code of the 
control vector first noticed to be missing. If more than one control vector is miss- 
ing, only the first omission is reported. The second byte of the sense code specific 
field is set to X'00'. 


REQUEST ERROR (CATEGORY CODE = X'10') 


This category indicates that the RU was delivered to the intended NAU component, but could not 
be interpreted or processed. This condition represents a mismatch of NAU capabilities. 


Category and modifier (in hexadecimal): 


1001 


1002 


1003 


1005 


RU Data Error: Data in the request RU is not acceptable to the receiving component; 
for example, a character code is not in the set supported, a formatted data field is 
not acceptable to presentation services, a value specified in the length field (LL) of 
a structured field is invalid, or a required name in the request has been omitted. 


RU Lergth Error: The request RU was too long or too short. 
Function Not Supported: The function requested is not supported. The function may 
have been specified by a formatted request code, a field in an RU, or a control char- 


acter. 


Parameter Error: A parameter modifying a control function is invalid, or outside the 
range allowed by the receiver. 
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1007 Category Not Supported: DFC, SC, NC, or FMD request was received by a half-session not 
supporting any requests in that category; or an NS request byte 0 was not set to a 
defined value, or byte 1 was not set to an NS category supported by the receiver. 


1008 Invalid FM Header: The FM header was not understood or translatable by the receiver, 
or an FM header was expected but not present. This sense code is sent in FMH-7 or 
UNBIND. 


Bytes 2 and 3 may contain the following sense code specific information: 
0000 Reserved. 


200E Invalid Concatenation Indicator: The concatenation indicator is on but concat- 
enation is not allowed. 


2010 FM Header and Associatcu data Mismatch: The FM header indicated associated data 
would or would not follow (e.g., FM header 7 followed by log data, or FM header 
EF Yollowed by program tnitialization parameters), but this indication was in 
error; or a previously received RU [e.g., -RSP(0846)] implied that an FM header 
would follow, but none was rece: ved. 


4001 Invalid FM Header Type: The type of the FM header is other than 5, 7, or 12. 


6000 FM Header Length Not Correct: The value in the FM header Length field differs 
from the sum of the lengths of the subfields of the FM header. 


6005 Invalid Access Security Information length or invalid Access Security Informa- 
tion subfield length. 


6009 Invalid Parameter Length. The field that specifies the length of fixed-length 
parameters has an invalid setting. 


600B Unrecognized FM Header Command Code: The partner LU received an FM header com- 
mand code that it does not recognize. For LU 6.2, this sense data is sent only 


6011 Invalid Logical Unit of Work: The LUH Length field (in a Compare States GDS 
variable or an FMH-5) is incorrect or the LUN is invalid or a LUWID is not pres- 
ent but is required by the setting of the synchronization level field. 


6021 Transaction Program Name Not Recognized: The FMH-5 Attach command specifies a 
transaction program name that the receiver does not recognize. This sense data 
is sent only tn FMH-7. 


6031 PIP Not Allowed: The FMH-5 Attach command specifies program initialization 
parameter (PIP) data is present but the receiver does not support PIP data for 
the specified transaction program. This sense data is sent only in FMH-7. 


6032 PIP Not Specified Correctly: The FMH-5 Attach command specifies a transaction 
program name that requires program initialization parameter (PIP) data and 
either the FMH-5 specifies PIP data is not present or the number of PIP sub- 
fields present does not agree with the number required for the program. This 
sense data is sent only in FMH-7. 


6034 Conversation Type Mismatch: The FMH-5 Attach command specifies a conversation 
type that the receiver does not support for the specified transaction program. 
This sense data is sent only in FMH-7. 


6040 Invalid Attach Parameter: A parameter in the FMH-5 Attach command conflicts 
with the statement of LU capability previously provided in the BIND negotiation. 


6041 Synchronization Level Not Supported: The FMH-5 Attach command specifies a syn- 


chronization level that the receiver does not support for the specified trans- 
action program. This sense data is sent only in FMH-7. 


This category indicates a sequence number error, or an RH or RU that is not allowed for the 
receiver's current session control or data flow control state. These errors prevent delivery of 
the request to the intended half-session component. 
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RH USAGE 


Category and modifier (in hexadecimal): 


2001 Sequence Number: Sequence number received on normal-flow request was not 1 greater 
than the last. 


2002 Chaining: Error in the sequence of the chain indicator settings (BCI, ECI), such as 
first, middle, first. 


2003 Bracket: Error resulting from failure of sender to enforce bracket rules for session. 
(This error does not apply to contention or race conditions. ) 


2004 Direction: Error resulting from a normal-flow request received while the hal f-duplex 
flip-flop state mas not Receive. 


2008 No Begin Bracket: An FMD request specifying BBI=BB was received after the receiver 
had previously received a BRACKET INITIATION STOPPED request. 


2009 Session Control Protocol Violation: An SC protocol has been violated; a request; 
allowed only after a successful exchange of an SC request and its associated positive 
response, has been received before such successful exchange has occurred (e.g., an FMD 
request has preceded a required CRYPTOGRAPHY VERIFICATION request). The request code 
of the particular SC request or response required, or X'00' if undetermined, appears 
in the fourth byte of the sense data. 


200A Immediate Request Mode Error: The immediate request mode protocol has been violated 
by the request. 


2008 Queued Response Error: The Queued Response protocol has been violated by a request, 
i.e.) QRI=-QR when an outstanding request had QRI=QR. 


200E Response Correlation Error: <A response was received that cannot be correlated to a 
previously sent request. . 


200F Response Protocol Error: A violation has occurred in the response protocols e.g., a 
#+RSP to an RQE chain was generated. 


2010 BIS Protocol Error: <A BIS protocol error was detected; e.g., a BIS request was 
received after a previous BIS was received and processed. 


2011 Pacing Error: A normal-flow request is received by a half-session after the pacing 
count has been reduced to 0 and before a pacing response has been sent. 


2012 Invalid Sense Code Received: A negative response was received that contains an 
SNA-defined sense code that cannot be used for the sent request. 


ERROR (CATEGORY CODE = X'40')} 


EEE 


This category indicates that the value of a field or combination of fields in the RH violates 
architectural rules or previously selected BIND options. These errors prevent delivery of the 
request to the intended half-session component and are independent of the current states of the 
session. They may result from the failure of the sender to enforce session rules. Detection by 
the receiver of each of these errors is optional. 


Category and modifier (in hexadecimal): 


4003 BB Not Allowed: The Begin Bracket indicator (BBI) was precuiee incorrectly, e.g.» 
BBI=BB with BCI=~BC. 


4004 CEB or EB Not Allowed: The Conditional End Bracket indicator (CEBI) or End Bracket 
indicator (EBI) was specified incorrectly, e.g., CEBI=CEB when ECI=~EC or EBI=EB with 
BCI=-BC, or by the primary half-session when only the secondary may send EB, or by the 
secondary when only the primary may send EB. 


4005 Incomplete RH: Transmission shorter than full TH-RH. 
4006 Exception Response Not Allowed: Exception response was requested when not permitted. 
4007 Definite Response Not Allowed: Definite response was requested when not permitted. 
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4008 


4009 
400A 


400B 


400C 


400D 


400F 


4010 


4011 


4012 


4013 


4014 


4015 
4016 
4017 


4018 


4019 


4021 


Pacing Not Supported: The Pacing indicator mas set on a request, but the receiving 
half-session or boundary function half-session does not support pacing for this ses- 
sion. | 


CD Not Alloned: The Change Direction jndientor (CDI) was speci fied incorrectly, @.g.>» 
CDI=CD with ECI=-EC , or CDI=CD with EBI= EB. ; 


No-Response Not Allowed: No-response was specified on a request when not PerMPttce: 
(Used only on EXR.) 


Chaining Not Supported: The chaining indice tors (BCI and ECI) were specified incor- 
rectly, e.g.» chaining bits indicated other than (BC,EC), but multiple- request chains 
are not supported for the session or for the category specified in the request header. 


Brackets Not Susported: The bracket i ndidators (BBI, CEBI, and EBI) were specified 
incorrectly, e.g., a bracket indicator was set (BBI=BB, CEBI=CEB, or EBI=EB), but 
brackets are not used for the session. , 


CD Not Supported: The Change-Direction indicator was set, but is not supported. 


Incorrect Use of Format Indicator: The Format indicator (FI) was specified incorrect- 


ly, e.g., FI was set with BCI=-BC, or FI was not set on a DFC request. 


Alternate Code Not Supported: The Code Sele:tion indicator (CSI) was set phen not sup- 
ported for the session. 


Incorrect Specification of RU Category: The RU Category indicator was specified incor- 


rectly, e.g.» an expedited-flow request or Response was specified with RU Category 


indicator = FMD. 


Incorrect Specification of Request Code: The request code on a response does not 
match the request code on its corresponding request. 


Incorrect Specification of (SDI, RTI): The Sense Data Included indicator (5DI) and the 
Response Type indicator (RTI) were not specified properly on a response. The proper | 
value pairs are (SDI=SD, RTI=negative) and (SDI=-SD, RTI=positive). 


Incorrect Use of (DRII, DR2I, ERI): The Definite Response 1 indicator (DRII), Definite 


Response 2 indicator (DR2I), and Exception Response indicator (ERI) were specified 


incorrectly, e.g., a SIGNAL request was not specified with DRII=DR1, DR2I=-DR2, and 
ERI=~ER. 


Incorrect Use of QRI: The Queued Besocnse indicator (QRI) was specified tncorrectly, 
@.g.» QRI=QR on an expedited-flow request. | 


Incorrect Use of EDI: The Enciphered Data indicator (EDI) was specified incorrectly, 
e.g.» EDI=ED on a DFC request. , 


Incorrect Use of POI: The Padded Data indicator (PDI) was specified incorrectly, e.g.» 
PDI=PD on a DFC request. 


Incorrect Setting of QRI with Bidder's BB: The first speaker half-session received a 
BB chain requesting use of a session (via LUSTAT(X'0006')), but the QRI was specified 
incorrectly, i.e., QRI = -QR. 


Incorrect Indicators with Last-In-Chain Request: A last-in-chain request has speci- 
fied incompatible RH settings, e.g., RQE*, CEBI=-CEB, and CDI=-CD. 


QRI Setting in Response Different From That in Request: The QRI setting in the 
response differs from the QRI setting in the corresponding request. 


OR (CATEGORY CODE = x 80') 


This category indicates that the request could not be delivered to the intended receiver, 
because of a path outage, an invalid sequence of activation requests, or one of the listed path 
information unit (PIU) errors. (Some PIU errors fall into other categories, e.g., sequence nun- 
ber errors are category X'20'.)} A path error received while the session is active generally 
indicates that the path to the session partner has been pear 


Category and modifier Cin Ratadectuel): 
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8001 


8002 


8003 


8004 


8005 


8006 


8007 


8008 


8009 


800B 
800C 
800E 


800F 


8010 


8013 


Intermediate Node Failure: Machine or program check in a node providing intermediate 
routing function. <A response may or may not be possible. 


Link Failure: Data link failure. 


NAU Inoperative: The NAU is unable to process requests or responses, e.g., the NAU has 
been disrupted by an abnormal termination. 


Unrecognized Destination: A node in the path has no routing information for the des- 
tination specified either by the SLU name in a BIND request or by the TH. 


Bytes 2 and 3 may contain the following sense code specific information: 
0000 No specific code applies. 


0001 A request was received by a gateway function that could not be rerouted because 
of invalid or incomplete routing information. 


No Session: No half-session is active in the receiving end node for the indicated 
origination-destination pair, or no boundary function half-session component is active 
for the origin-destination pair in a node providing the boundary function. A session 
activation request is needed. 

Bytes 2 and 3 may contain the following sense code specific information: 

0000 No specific code applies. 


0001 The receiver received a request other than session control request when no LU-LU 
session was active. 


0002 The receiver received a request other than session control request when no 
LU-SSCP session was active. 


0003 The receiver received a session control request other than BIND/UNBIND when no 
LU-LU session was active. 


0004 The receiver received an UNBIND when no LU-LU session mas active. 


0005 The receiver received a session control request other than ACTLU/DACTLU for the 
LU-SSCP session when no LU-SSCP session was active. 


0006 The receiver received DACTLU when no LU-SSCP session was active. 

Invalid FID: Invalid FID for the receiving node. (Note 1) 

Segmenting Error: First BIU segment had less than 10 bytes; or mapping field sequenc- 
ing error, such as first, last, middle; or segmenting not supported and MPF not set to 
11. (Note 2) 

PU Not Active: The SSCP-PU secondary half-session in the receiving node has not been 
activated and the request was not ACTPU for this half-session; for example, the 
request was ACTLU from an SSCP that does not have an active SSCP-PU session with the 
PU associated with the addressed LU. 


LU Not Active: The destination address specifies an LU for which the SSCP-LU second- 
ary half-session has not been activated and the request was not ACTLU. 


Incomplete TH: Transmission received was shorter than a TH. (Note 1) 
DCF Error: Data Count field inconsistent with transmission length. 
Unrecognized Origin: The origin address specified in the TH was not recognized. 


Invalid Address Combination: The (DAF',OAF') (FID2) combination or the LSID (FID3) 
specified an invalid type of session, e.g.» a PU-LU combination. 


Segmented RU Length Error: An RU was found to exceed a maximum length, or required 
buffer allocation that might cause future buffer depletion. 


COS Not Available: <A session activation request cannot be satisfied because none of 
the virtual routes requested for the session is available. 


Bytes 2 and 3 may contain the following sense code specific information: 
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Byte 2 indicates the environment in which the failure was detected: 
00 Single network 


01 Interconnected network: Failure was detected at a node in a subnetwork other 
than that of the NAU sending the activation request. 


Byte 3 indicates the reason for the session-activation failure: 


00 No Specific Code applies: This means an error occured, but none of the condi- 
tions listed below applies. 


01 No Mapping Specified: A session activation request cannot be satisfied because 
for each VR in the VR identifier list for the session, no VR to ER mapping is 
speci fied. | 


02 No Explicit Routes Defined: A session activation request cannot be satisfied 
because each VR in the VR identifier list for the session maps to a correspond- 
ing ER that is not defined. 


03 No VR Resource Available: <A session activation request cannot be satisfied 
because each VR specified in the VR identifier List for the session requires a 
node resource that 1s not available. 


04 No Explicit Routes Operative: A session activation request cannot be satisfied 
because no underlying ER is operative for any VR specified in the VR identifier 
list for the session. 


05 No Explicit Route Can Be Activated: A session activation request cannot be sat- 
isfied because no VR specified in the VR identifier list for the session mapped 
to a defined and operative ER that could be activated. 


06 No Virtual Route Can Be Activated: <A session activation request cannot be sat- 
isfied because no VR specified in the VR identifier list for the session can be> 
activated by the PU, though for at least one VR an underlying ER is defined, 
operative, and activated. 


07 No Virtual Route Identifier List Available: A session activation request cannot 
be satisfied because a VR identifier list is not available. 


Note: If none of the virtual routes specified in the VR identifier list for the ses- 
sion is active or can be activated, the reported reason is set based on a hierarchy of 
failure events. The "highest" of the failures that occurred within the set of virtual 
routes is returned on the response. For example, if the VR manager receives a nega- 
tive response to an NC_ACTVR request for a VR specified in the VR identifier list and 
for all other VRs in the list no VR to ER mapping is specified, then reason X'06' is 
reported. The hierarchy of the failure reasons is in ascending numeric order (e.g.>» 
reason X'02' is higher than reason X'01'). 


Notes: 
1. It is generally not possible to send a response for this exception condition, since informa- 
tion (FID, addresses) required to generate a response is not available. It is logged as an 


error if this capability exists in the receiver. 


2. If segmenting is not supported, a negative response is returned for the first segment only, 
since this contains the RH. Subsequent segments are discarded. 
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ENDIX H. FM HEADER AND LU SERVICES COMMANDS 


Throughout this appendix the same symbol-string types are used as defined in "Appendix E. 
Request/Response Unit (RU) Formats". The symbol-string types define the character sets that LUs 
and transaction programs use to specify the symbol strings used in RUs. 

Figure H-1 defines the send and receive support for each symbol string in terms of the 
symbol-string types. Depending on the symbol string, support is defined by either a single type 


or multiple types. Where multiple types are indicated, the type selected is 
implementation-defined and send support may differ from receive support. 


Symbol String 


Support Support 
A | A 
’ 


[rose tene 
Transaction Program Name [2] AE, GR, or DB’ |A, AE> GR, or DB 
Access Security Information Subfields AE, GR, or DB {A>, AE» GR» or DB 


Program Initialization Parameters (PIP) Pe 


Conversation Correlator 


Session Instance ID PG 


NOTES: 


1. The fully qualified LU name consists of two symbol strings of 
type A concatenated by a period (.). The left-hand symbol 
string represents the network ID; the right-hand symbol 
string represents the network LU name. The period is not 
part of the network ID or the network LU name. 


2. The first character of an SNA-defined service transaction 
program name is aeocharacter ranging in value from X'00' 
through X'0D' and X'10' through X'3F' (excluding X'OE' and 
X'OF). The remaining characters of the name are _ type-A 
without any restriction on the first type-A character. A 

list of SNA-defined service programs is given in "SNA-Defined 

Transaction Program Names" on page H-15. 


The LU-LU password is a locally-specified value and is not 
sent outside the LU. The symbol-string type is G. 


Figure H-1. Symbol-String Types 
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The Sumbeiccening length represents the qeber: of characters a symbol string can contain. Three 
symbol-string lengths are defined: : 


@¢ Minimum specification length: the minimum number of characters that a transaction program 
is allowed to use to specify the symbol string. For some symbol strings, the minimum spec- 
ification length is 0. Zero-length strings are valid symbol strings and are subject to the 
same usage conditions as nonzero-length strings that fulfill the definition of the specific 
symbol-string type (or range of types) allowed. 


¢ Maximum send support: the maximum number of characters that every implementation can send 
in the symbol string. | : 


e Maximum receive support: the maximum number of characters that every implementation can 
receive in the symbol string. 


The maximum send or receive support for a symbol-string's length is defined either by a single 
value or within a range of values, depending on the symbol string: 


e The single value is the maximum number of characters in a symbol string that every implemen- 
tation can send or receive. 


® The range of values represents a lower and upper bound of the maximum number of characters 
in a symbol string that an implementation can send or receive. The specific maximum number 
of characters an implementation can send or receive for each of these symbol strings is 
implementation-defined within the range. Compatibility in the maximum lengths allowed by 
sender and receiver is a concern of system definition and program design. 


Figure H-2 on page H-3 defines the product maximum send and receive support for each symbol 
string in terms of the symbol-string lengths. Where support is defined to be within a range of 
values, the range is given as "lower-value<—>upper-value," which identifies the lower and upper 
bounds of the range. 


The variable to which a type-A» type-AE, or type-GR symbol string is assigned may be longer than 
the symbol string; in this case, the symbol string is left-justified within the variable and the 
variable is filled out to the right with space (X'‘'40') characters. Space characters, if pres- 
ent, are not part of the symbol string. If the symbol string is formed from the concatenation 
of two or more individual symbol strings, such as the fully qualified LU name, the concatenated 
symbol string as a whole is left-justified within the variable and the variable is filled out to 
the right with space characters. Space characters, if present, are not part of the concatenated 
symbol string. 
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Length 
Symbol String Minimum Maximum Maximum 
Specification Send Support Receive Support 


Ce 
a 
[pai eaified wee 
a 
Ciresetion Fromea tame 
[reset te 
[convertion corinne 
[Sesion tates 

a 

ce 


The name of an SNA_ service transaction program can be one to four 
characters in length; typically, however, they are four characters in 
length. 


Support of PIP subfields is optional, and send support is independent of 
receive support. The maximum number of PIP subfields an implementation 
can send or receive is implementation-defined; it is any number greater 


than or equal to 16. 

The maximum send support for PIP subfields is implementation-defined. 

The maximum receive support for PIP subfields is implementation-defined. 
LU-LU passwords are 64 bits (8 bytes). Product designs may allow shorter 
passwords to be entered, in which case the passwords are filled to the 
right with binary O's. 


The zero-length map name has a special meaning: it indicates mapping Is 
not to be performed by the LU. 


Figure H-2. Symbol~String Lengths 
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FM HEADERS 


This section explains how function management (FM) headers are used to exchange information by 
LU 6.2. It also defines the formats of the FM headers and how they are related to other data in 
request units. Z : 3 : 


The request header (RH) contains a format indicator (FI) that, when on» indicates that an FM 
header is at the beginning of the RU; FM headers may appear only singly at the beginning of an 
RU. The RU containing the FM header may appear anywhere within a chain. 


The placement of FM headers within a request unit is shown below: 


FM Header Contained in One RU: 


ee er a ae aren pee ee ep ee oe et ge ee ee ee 
] RH: FMH, *BC,xEC | FM header | Data l 
eee ene IRENE: Pree SARL MUEE Et: OTe eee eee | 


FM Header Contained in Teo Contiguous RUs of a Chain: 


ee ep eee EE a ae ae CI hE eee TR Re ee ogee ee oe 
| RH: FMH, *BC,~EC | First of FM header j 
| AEE SRE, NRE Se een a ene eee See eR nee ME EE ORR EAE SE | 
| CRBC RISE SE ee EES cen cae Ree ee CD au a ae sia mess | 
| RH: -FMH,-BC,xEC | Rest of FM header | Data | 
| Eee ee aE, SERS eee eee! COMET Ree 


NOTE: FM headers are placed at the beginning of a request unit, but not necessarily the 
first or last request unit of a chain. When the FM header is longer than one RU will hold, 
the FM header is continued in as many additional RUs as are needed to hold it. 


Figure H-3. Examples of FM Header Placement 


H-4 SNA Format and Protocol Reference Manual for LU Type 6.2 


The following FM headers are used by LU 6.2: 


FMH-5 carries a request for a conversation to be established between two transaction pro- 
grams. identifies the transaction program that is to be put into execution and comected to 
the receiving half-session. 


When a transaction program issues an ALLOCATE verb (see SNA Transaction Programmer's Refer- 
ence Manual for LU Type 6.2 for details) naming a transaction program to be run at the other 
end of the conversation, an Attach FMH-5 carries the transaction program name (TPN) to the 
receiving LU. 


FMH-7 carries information that relates to an error on the session or conversation. For 
example, an FMH-7 and additional error information are sent when an FMH-5 specifies a nonex- 
istent transaction program name. 


FMH-12 carries the enciphered version of the random data found in the Random Data Subfield 
received in the +RSP(BIND); the encryption uses the DES = algorithm and the 
installation-defined LU-LU password as cryptographic key. FMH-12 is used for LU-LU password 
verification. 


The formats for these FM headers are shown below. 
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FM header 5: 


Attach 


The function management header 5 (FMH-5), with a command of Attach, has the following format. 


m+] 


mt2-n 
m+2 
m+ 3-ba 


w+ 1 ~w+6 
wt 7 
wt8(=n) 
n+] 
n+2-p 


Note 1: 


Length, in binary, of FMH-5, ineluding this Length byte 
bit 0, reserved 
bits 1-7, type: 0000101 
Command code: X'O2FF' (Attach) 
bit 0, security indicator: 
0 user ID is not already verified 
l user ID is already verified 
bits 1-3, reserved 
bit 4%») program initialization parameter (PIP) presence: 
0 PIP not present following this FMH-5 
1 PIP present following this FMH-5 (see "PIP Variable " on page H-7 for for- 
mat) 
bits 5-7, reserved 
Length (3), in binary, of Fixed Length Parameters field (currently 3--future expansion 
possible) 
Eixed Length Parameters 
Resource type: 
X'DO' basic conversation 
X'D1' mapped conversation 
Reserved 
bits 0-1, synchronization level: 
00 none 
01 confirm 
10 confirm, syne point, and backout 
1l reserved 7 
bits 2-7, reserved 
Variable Length Parameters 
Length (values 1 to 64 are valid), in binary, of transaction program name 
Transaction program name (see Figure H-1 on page H-1 for valid formats) 
Length (0 or m-k-1), in binary, of Access Security Information subfields 
Zero or more Access Security Information subfields (see “Access Security Information 
Subfields "on page H-7 for format) 
Length (values 0 and 10 to 26 are valid), in binary, of Logical-Unit-of-Work Identifi- 
er field 
Logical-Unit-of-Work Identifier 
Length (values 1 to 17 are valid), in binary, of fully qualified LU network name 
Fully qualified LU network name (format described in "User Data Structured Subfield 
Formats" in "Appendix E. Request/Response Unit (RU) Formats’’) 
Logical-unit-of-work instance number, in binary 


Logical-unit-of-work sequence number, in binary 

Length (values 0 to 8 are valid), in binary, of conversation correlator of sender 
Conversation correlator of the sending transaction: a 1l- to 8-byte identifier Cunique 
within the sending LU) of the conversation being allocated via FMH-5 (an example con- 
struction of this field would be the composition of a transaction program instance 
identifier and a resource identifier) 


Trailing Length fields (bytes ntl, mtl, and k+l) that have value X'00' can be omitted. 


Note 2: In FMH-5, the offset "m" represents the end of the last subfield. 
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Access Security Information Subfields 


The Access Security Information subfields in FMH-5 have the following formats: 


0 Length (valid values are 1 to 11), in binarys of remainder of subfield--does not 
include this Length byte 
I Subfield type: 


X'00' profile 
X'O1' password 
X'02' user ID 
2-1 Data (see Figure H-1 on page H-1 for the symbol-string type and Figure H-2 on page H-3 
for the symbol-string length restrictions) 
Note: The Access Security Information subfields may appear in any order in the Access Security 
Information field of the FMH-5. 


PIP Variable 
The PIP variable following FMH-5 Attach has the following format: 


0-1 Length (4 or n+l), in binary, of PIP variable, including this Length field 

2-3 GDS indicator: X'12F5' 

4-n Zero or more PIP subfields, each of which has the following format (shown using 
zero-origin) 

0-1 Length, in binary, of PIP subfield, including this Length field 

2-3 GDS indicator: X'12E2' 

4G-m PIP subfield data (see Figure H-1 on page H-1 for the symbol-string type and Fig- 
ure H-2 on page H-3 for the symbol-string length restrictions) 
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FM header 7: Error Description 


The function management header 7 (FMH-7) has the following format: 


Length (7), in binary, of FMH-7, including this Length byte 
bit 0, reserved | 
bits 1-7, type: 0600111 
SNA-defined sense data (see below) 
bit 0, error log variable presence: 
0 no error log variable follows this FMH-7 
1 error log GOS variable follows this FMH-7 
bits 1-7, reserved 


The following sense data (in hexadecimal) can be sent in an FMH-73 see "Appendix G. Sense Data" 
for additional details on the sense data; The phrases following the sense data are the symbolic 
return codes provided to the application program in LU 6.2 verbs (see SNA Transaction Program- 
mer's Reference Manual for LU Type 6.2) when the sense data is received. 


Sense Data 


1008600B 
10086021 
10086031 
10086032 
10086034 
10086041 
O80F6051 
08240000 
084B6031 
084C0000 
08640000 
08640001 
08640002 
08890000 
08890001 
08890100 


08890101 


re 


Return Code 

RESOURCE_FAILURE_NO_RETRY 
ALLOCATION_ERROR--TPN_NOT_RECOGNIZED 
ALLOCATION_ERROR--PIP_NOT_ALLOWED 
ALLOCATION_ERROR--PIP_NOT_SPECIFIED_CORRECTLY 
ALLOCATION_ERROR--CONVERSATION_TYPE_MISMATCH 
ALLOCATION_ERROR--SYNC_LEVEL_NOT_SUPPORTED_BY_PGM 
ALLOCATION_ERROR--SECURITY_NOT_VALID 
BACKED_OUT 
ALLOCATION_ERROR--TRANS_PGM_NOT_AVAIL_RETRY 
ALLOCATION_ERROR--TRANS_PGM_NOT_AVAIL_NO_RETRY 
DEALLOCATE_ABEND_PROG 

DEALLOCATE_ABEND_SVC 

DEALLOCATE_ABEND_ TIMER 

PROG_ERROR_NO_TRUNC or PROG_ERROR_PURGING 
PROG_ERROR_TRUNC 

SVC_ERROR_NO_TRUNC or SVC_ERROR_PURGING 


SVC_ERROR_TRUNC 
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FM header 12: Security 


The function management header 12 (FMH-12) has the following format: 


0 Length (10), in binary, of FMH-12, including this Length byte. 
1 bit 0, reserved 

bits 1-7, ty,at 0001100 
2-9 Enciphered version of the random data received in RSP(BIND) 
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PRESENTATION SERVICES (PS) HEADERS 


H-10 


Presentation services (PS) headers convey information between PS component sync point managers 
when the conversation using the session is allocated with the sync-point synchronization level. 
“Chapter 5.3. Presentation Services--Syne Point Services Verbs" describes the use of these PS 
headers. | oe 


Transaction program data is delimited using a 2-byte length field called an LL; containing a 
value that is the number of bytes contained in the transaction program data plus 2 (the length 
of the LL field itself). 


— SS ee 
i wu | transaction program data / 
Een cans) (ANA tere Rere sen rere en ee it reer eM eae ee eae eI, 


All PS headers are identified by an LL of X'0001' immediately preceding the header. X'0001' is 
an invalid LL value for use by transaction programs because the Li's value must include the 
length of itself, which is 2 bytes. Therefore, all LLs indicating a length of less than 2 are 
reserved for use by the LU. The format of PS headers is shown below. 


PS header 10: Syne Point Control 


Presentation services header 10 (Syne Point Control) has the following format: 


0 Length, in binary» of PS header, including this length field 
1 bit 0, reserved 

bits 1-7, type: 0001010 sync point control Conly value defined) 
2-3 Syne point command type: 


X'0005' Prepare 
X'0006' Request Commit 
X'0007' Committed 
X'0008' Forget 
X'0009' Heuristic Mixed 

4-5 Modifier specifying next flow (present only if bytes 2-3 = X'0005" or X'‘'0006'3 
reserved when bytes 2-3 = X'0006' and 2-phase syne point being used): 
X'0000' request RECEIVE 
X'0001' request DEALLOCATE 
X'0002' request SEND 
Note: Bytes 4-5 affect the CD and CEB settings generated by data flow control on the 
last PS header in the syne point sequence, i.e., Forget if Prepare was received, and 
Committed if Request Conmit was the first PS header received (see "Chapter 5.3. Pres- 
entation Services--Synec Point Services Verbs" for details). 
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FORMATS OF RECORDS USED BY LU 6.2 SERVICE TRANSACTION PROGRAMS 


A TPN value starting with X'06' in the Attach header indicates that the LU resources manager is 
to initiate execution of one of the LU service transaction programs. 


LU services managers exchange data directly via GDS variables. A group of 6DS IDs of the form 
X'12%*' is assigned for use by the LU service transaction programs; the commands use a Service 
Flag (SF) byte (following the GDS ID) to denote the processing options of the command; the spe- 
cific options are encoded in the last four bits of the Service Flag byte as shown in the indi- 
vidual GDS variables. Requests have bit 4 set to 0 and replies have bit 4 set to 13; therefore; 
requests and replies have the same ID values. The first four bits are unique to the command. 


_ Appendix H. FM Header and LU Services Commands H-11 


Change Number of Sessions (CNOS) 


See "Chapter 5.4. Presentation Services--Control-Operator Verbs" for a detailed: description of 
the use of this command. 


0-1 Length (17 or nt!), in binary, of Change Number of Sessions 60S variable, including 
this Length field 

2-3 6DS ID: xX‘'1210' 

& Service flag: 


bits 0-3, reserved 
bits 4-7, request/reply indicator: 
0010 request 
1000 reply, function completed abnormal 
1010 reply, function accepted but not yet completed 
5 Reply modifier (reserved if byte 4, bits 4-7 = 0010): 
X'00' normal--no negotiation performed 
X'O1l' abnormal--command race detected 
X'02' abnormal--mode name not recognized 
X'03' reserved 
X'04' normal--negotiated reply 
X'05' abnormal--(LU,mode) session limit is 0 
6 Action: 
X'00' set (LU,mode) session limits 
X'O1' reserved 
X'02' close 
7 Drain immediacy: 
bits 0-2, reserved 
bit 3, source LU drain (reserved if byte 6 ~= 02): 
0 no (send BIS at next opportunity) 
l yes 
bits 4-6, reserved 
bit 7, target LU drain (reserved if byte 6 ~= 02): 
0 no (send BIS at next opportunity) 
1 yes 
8 Action flags: 
bits 0-6, reserved 
bit 7, session deactivation responsibility: 
0 sender of Change Number of Sessions request (source LU) 
} receiver of Change Number of Sessions request (target LU) 
Note: Bytes 9-14 are reserved if byte 6 -= 0. 
9-10 (LU,mode) session limit: 
bit 0, reserved | 
bits 1-15, maximum (LU,mode) session count, in binary 
11-12 Source LU contention winners: 
bit 0, reserved 
bits 1-15, guaranteed minimum number of contention winner sessions at source LU, in 
binary 
13-14 Target LU contention sinners: 
bit 0, reserved 
bits 1-15, guaranteed minimum number of contention winner sessions at target LU, in 
binary 
15 Mode name selection: 
bits 0-6, reserved 
bit 7, mode names affected by this command: 
0 a single mode name is affected 
1 all mode names are affected 


16 Length (values 0 to 8 are valids reserved if byte 15, bit 7 = 1), in binary, of mode 
name 
l7-n Mode name (omitted if byte 16 = X'00') 
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Exchange Log Name 


See "Chapter 5.3. Presentation Services--Syne Point Services Verbs" for a detailed description 
of the use of this command. 


Length (ptl), in binarys of Exchange Log Name GDS variable, 
field 
GOS ID: xX'l2ll' 
Service flag: 
bits 0-3, reserved 
bits 4-7, request/reply indicator: 
0010 request 
1000 reply, function completed abnormally 
1001 reply, function completed normally 
Syne point manager flags: 
bits 0-6, reserved 
bit 7, log status: 
0 cold 
1 warm 


including this Length 


Length (values 1 to 17 are valid), in binary, of fully qualified LU network name 
Fully qualified LU network name (format described in "User Data Structured Subfield 


Formats" in "Appendix E. Request/Response Unit (RU) Formats") 
Length (values 1 to 64 are valid), in binary» of log name 
Log name (symbol-string type-AE) 


Appendix H. FM Header and LU Services Commands H-13 


H-14 


Compare States 


See "Chapter 5.3. Presentation Services--Syne Point Services Verbs" for a detailed description 
of the use of this command. 


1 
=3 


sale alr 


© © & 


wt+l-w+6 
wt 7 
wt+8C=n) 
n+1 
nt+2-q 


qtl 
qt2-p 


Length (p+1), in binary, of Compare States GDS variable, including this Length field 
GOS ID: xX‘'1213' 
Service flag: 
bits 0-3, reserved 
bits 4-7, request/reply indicator: 
0010 request 
1000 reply, function completed abnormally 
1001 reply, function completed normally 
Syne point manager state: 
X'O1l' RESET 
X'02' SYNC_POINT_MANAGER_PENDING 
X'03' IN_DOUBT 
X'04' COMMITTED 
X'O05' HEURISTIC_RESET 
X'06' HEURISTIC _COMMITTED 
X'07' HEURISTIC_MIXED 
Reserved 
Length, in binary, of Logical-Unit-of-Work Identifier field (values 10 to 26 are val- 
id) 
Logqical-Unit-of-Work Identifier 
Length, in binary, of fully qualified LU network name (values 1 to 17 are valid) 
Fully qualified LU network name (format described in "User Data Structured Subfield 
Formats" in "Appendix E. Request/Response Unit (RU) Formats'') 
Logical-unit-of-work instance number, in binary 


Logical-unit-of-work sequence number, in binary 

Length (values 0 to 8 are valid), in binary, of conversation correlator 

Conversation correlator of transaction program that allocated the conversation. that 
failed: see FMH-5 for format of this correlator 

Length (values 2 to 8 are valid), of session instance identifier 

Session instance identifier of session being used by conversation at time of failure 
(See "User Data Structured Subfield Formats" in "Appendix E. Request/Response Unit 
(RU) Formats" for the format of this tdentifier.) 
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SNA-DEFINED TRANSACTION PROGRAM NAMES 


The following transaction program names (TPNs) specify SNA-defined service transaction programs 
discussed in this book. 


TPN Service Transaction Program 
X'06FI1' Change Number of Sessions 
X'06F2' Compare States and Exchange Log Name 
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DS VARTABLES 


ererienree 
’ 


The following chart indicates (using an "X") each GDS variable code point (with first byte 


X'12') used by LU 6.2. 


Patmos) 


First hexadecimal digit 
rsecond hexadecimal digit 


The code points used by LU 6.2 are: 


X'1210° 
X'lell' 
X'1213' 
X'12A0' 
X'12E1' 
X'12E2' 
X'1leF1' 
A'leFe2' 
X'12F3" 
A'1eF4' 
X'12F5' 
X'12FF! 


—H-16 


Change Number of Sessions 
Exchange Log Name 
Compare States 
Workstation Display Passthrough 
Error Log 

PIP Subfield Data 

Null Data 

User Control Data 

Map Name 

Error Data 

PIP Data 

Application Data 
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FORMAT OF APPLICATION DATA GDS VARIABLE 


The Application Data GDS variable, ID X'12FF', contains application data. The application 
transaction program's data as specified in the MC_SEND_DATA verb is (optionally) mapped and then 
sent as X'12FF' variables. 


FORMAT OF NULL DATA VARIABLE 


The Null Data GDS variable, ID X'l2@F1', contains no application data. This variable may 
optionally be generated (see "Chapter 5.2. Presentation Services--Mapped Conversation Verbs") to 
carry certain control information (e.g.,» Confirm) when no application data 1s available. 


FORMAT OF USER CONTROL DATA GDS VARIABLE 


The User Control Data GDS variable, ID X'12F2', contains user control data. The meaning of this 
data is known only to the LU Services Component Programs or the transaction programs and their 
mapping programs. This data can be used, for example, as prefix control information for an 
Application Data GDS variable that follows it or to carry FM Header Data for a mapped conversa- 
tion transaction. 


FORMAT OF MAP NAME GDS VARIABLE 


The Map Name GDS variable, ID X'12F3', is followed by a 0- to 64-byte map name. See Figure H-1 
on page H-1 for the valid map name symbol-string type. 
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Format of an Error Data 6DS variable 


The Error Data 60S variable, ID X'12F4', is used to convey information about mapping errors. It 
is sent using the SEND DATA verb following a SEND_ERROR verb. Its format is: 


te | Length (ntl), in binary, of Error Data GDS variable, including this Length field 
2-3 GDS ID: X'12F4' 
4-7 Error code: 

X'00010000' Invalid GOS ID: The mapped conversation verb component (see "Chapter 5.2. 
Presentation Services--Mapped Conversation Verbs") encountered a GOS ID 
that it did not recognize. 

X'00030001' Map Not Found: The specified map was not available at the target, or 
access to the referenced map could not be completed. 

X'00030002' Map Execution Failure: The map program was not able to process the data 
stream. 

8 Length (n-8), in binary, of error parameter 
9-n Error parameter: for a mapping failure, the map name carried in the GDS variable for 
which the error occurred; for an invalid 6DS ID, the 2-byte GDS ID that mwas not recog- 


nized 
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Format of Error Log 6DS Variable 


The Error Log GDS variable, ID X'12E1', following an FMH-7 conveys implementation-specific error 
information to an LU, where it is added to the system error log for use in debugging and error 
recovery. It is not used by SNA-defined service transaction programs (other than to log it) 
Since it contains tmplementation-specific data. The Error Log variable is sent as a consequence 
of issuing the SEND_ERROR verb, but ts not passed to the receiving transaction program. Its 
format is: 


0-1 Length (n+l), in binary, of Error Log GDS variable, including this Length field 

2-3 GDS ID: X'12E1' 

G-m Product Set ID 

4-5 Length, in binary, of Product Set ID, including this Length field (values 2 to 32,767 
are valid) 

Note: The Length field is always presents; a value of 2 indicates no Product Set ID 
subvector follows. 


6-m Product Set ID (X'10') subvector (format described in "Common Subvectors" on page 
E-24) 
wei-n Message Text 


m+l-m+2 Length, in binary, of message text, including this Length field (values 2 to 32,767 
are valid) 


Note: The Length field is always presents a value of 2 indicates no message text fol- 
lows. 


m+3-n Message text data: implementation-gpecific data 
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APPENOIX I. GENERAL DATA STREAM 


This appendix defines the general data stream 
(60S), which is used in a variety of ways by 
SNA products. For instance, it is used to 
encode the Document Interchange Architecture 
(DIA) message units. The basic structural 
unit in GDS is the structured field, a string 
of bytes preceded by a length and beginning 
with a GDS identifier (ID) that defines the 
structure of the remainder of the field. 
Some structured fields are used by components 
of SNA that are defined in this book; these 
uses are defined in “Appendix E. 
Request/Response Unit (RU) Formats" and "Ap- 


STRUCTURED FIELDS 


Each structured field has the format shown in 
Figure I-1. 


IDENTIFIER 
(Id) 


INFORMATION... 


pendix oH. FM Header and LU Services 
Commands". GDS IDs are assigned, generally 
in blocks of consecutive values, to different 
layers and components of SNA and to other 
interconnection architectures.. For a com- 
plete listing of these block assignments, see 
the SNA Reference Summary, 


The general data stream applies to data 
exchanged between nodes over SNA links, over 
non-SNA links, and to data exchanged via 
removable storage wmedia or shared storage 
facilities. 


Byte 0 2 4 N 


Figure I-1. 6DS Structured Field 


LENGTH (LL} DESCRIPTION 


Bits 1 to 15 of the LL contain a binary nun- 
ber from 4 through 32767, which is the 
length, in bytes, of the variable-length 
field that follows. Values 0 and 1 of the LL 
are reserved for use as escape sequences; 
values 2 and 3 are not used. For example, a 
value of X'O0001' indicates a presentation 
services header, which is used for sync point 
management. 


IDENTIFIER (ID) DESCRIPTION 


The 2-byte identifier that follows the length 
field describes the format and meaning of the 
data that follow. Sometimes additional val- 


Bit 0 of byte 0 (high-order bit) is used for 
a length continuation indicator, where a val- 
ue of 0 means last 60S variable segment, and 
a value of 1 means not-last segment. Some 
data streams built from structured fields use 
other methods to create data objects that are 
longer than a 15-bit length can specify. 


ues appearing in the information field are 
needed to completely specify the information 
field's content. 
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APPENDIX N. FSM NOTATION 


A finite-state machine (FSM) is a combination of processing and memory, where the memory con- 
sists of the state of the FSM. The state can take one of a small number of named values (the 
state names). An FSM is defined by a matrix that lists the states and specifies the processing 
to be performed when the FSM is called. This processing typically depends on the current state 
of the FSM and on the input passed to the FSM, and may change the FSM state (resulting in a 
state transition) and produce output. Within this matrix definition, each state is given a num- 
ber as well as its name, for notational convenience. 


A number of alternative FSM definitions may be grouped together as a generic FSM, the definition 
to be used being assigned dynamically. The assignment of a particular definition to be used at 
a given time is called the binding of the generic FSM. A generic FSM can also be assigned to be 
a "no operation." 


The following operations are performed on an FSM: 


® Call. Processing is performed as defined in the FSM definition for the existing combination 
of current state and input. This may involve a state transition. 


® State check. Validity checking is performed for the existing combination of current state 
and input. 


® State test. The current state of the FSM is tested for equality or inequality with a speci- 
fied value. 


An FSM is represented by a state-transition matrix. 


The synt:x of the state-transition matrix FSM definition is shown in Figure N-1 on page 2. The 
column headings give the FSM state names, while the row headings name the inputs to the FSMs. 
The matrix elements—(Crow,column) intersections—define the state transitions and output 
actions. 


Horizontal lines are used to group input lines together to improve readability. Their location 
has no bearing on the FSM function. For compactness, mnemonic abbreviations are used in the 
matrices. 


The input lines within the matrix are scanned from top to bottom at execution time. The first 
input line found with all its conditions true 1s used to address the matrix for the next state 
and the output code. No more than one input line in a matrix has all its conditions true during 
a scan. 


An FSM comes into existence initialized to state 1. If another state is to be the initial 
state, the FSM is initialized explicitly by calling the FSM with an appropriate signal. 


Calling an FSM executes the FSM; i.e.» an FSM action code is selected based on the current state 
of the FSM and the input line that is true. The input Line evaluation uses the parameters or 
Signal passed to the FSM. The FSM is scanned for a true input line from top to bottom of the 
matrix. 


If the next-state indicator is a number n, the FSM enters state n. If the next-state indicator 
is a state-check indicator (>), the call of the FSM would act as if a no-state-change indicator 
(-) were encountered. (In practice, the formal description checks for such conditions prior to 
calling an FSM in order to perform special error handling.) If the next-state indicator is a 
canmot-occur indicator (/), this is an execution-time error; calls of the FSM cannot encounter 
this indicator because previous logic has filtered out the input for that state of the FSM. 


If no input line is true, the CALL acts as if a no-state-change indicator (-) were encountered. 
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fname: 


STATE NAMES---~-> 


INPUTS STATE NUMBERS--> 


Legend: 
[ } = optional parameter 
fname = FSM name 


snam = state name component 
snum = state number : 
i¢ = input condition name 

= action code 


An action code (ac) has the syntax: ns[(oc)], where: 
next-state indicator 


output code (The parentheses around the oc are 
sometimes omitted to save space. ) 


NS 
oc 


Possible next-state indicators and associated action code 
formats are: 


nl (oce)] normal state transition to state n (corresponding 
to some snum) 
-[(oc)] same-state transition—remain in the same state | 
>E(o0¢)] error condition, no state change oo BN 
/ “cannot occur" condition, no state change 


Figure N-1. Syntax of an FSM State-Transition Matrix 
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SPECIAL CHARACTERS 


- (period), to separate name qualifiers 
denoting decomposition 1-5 

_ (underscore), in name phrases 1-5 

| (vertical stroke), to mean "ei- 
ther...or" 1-5 

& Campersand), to indicate composition in 
names 1-5 

* Casterisk), to mean “any value" or "don't 
care" 1-6 


oi 


ABORT_HS structure A-11 
referenced by 
FSM_STATUS 4-95 
PROCESS_ABORT_HS 4-77 
PROCESS _LU_LU_SESSION 6.0-4 
PROCESS_RECORD_FROM_HS 4-48 
Access Security Information Subfields H-7 
format H-7 
action codes 
calling result N-1 
ACTIVATE LOGICAL UNIT (ACTLU) 4-17, E-5 
ACTIVATE_NEEDED_SESSIONS procedure 3-22 
referenced by 
CHANGE_SESSIONS_PROC 3-37 
SESSION_DEACTIVATED_PROC 3-58 
ACTIVATE_SESSION_ERROR procedure 4-51 
referenced by 
PROCESS_ACTIVATE_SESSION 4-77 
ACTIVATE_SESSION_PROC procedure 5.4-36 
referenced by 
PS_COPR 5.4-32 
ACTIVATE_SESSION_RSP_PROC procedure 3-23 
referenced by 
PROCESS_LNS_TO_RM_RECORD 3-20 
ACTIVATE_SESSION_RSP structure A-20 
referenced b 
ACTIVATE_SESSION_RSP_PROC 3-23 
BUILD_AND_SEND_ACT_SESS RSP_NEG 4-56 
BUILD_AND_SEND_ACT_SESS_RSP_POS 4-57 
ACTIVATE_SESSION structure A-31 
referenced by 
ACTIVATE_NEEDED_SESSIONS 3-22 
ACTIVATE_SESSION_ERROR 4-51 
BUILD_AND_SEND_ACT_SESS_RSP_NEG 4-56 
INITIALIZE_LULU_CB_ACT_SESS 4-73 
PROCESS ACTIVATE _SESSION 4-77 
PROCESS_RECORD_FROM_RM 4-48 
SEND_ACTIVATE_SESSION 3-52 
ACTIVATE_SESSION verb 5.4-6, 5.4-20 
processing by PS.COPR 5.4-25 
activation, session 
CP-LU 4-2, 4-17 
Cold 4-17 
ERP 4-17 
LU-LU 4-3, 4-19 
ACTLU E-5 
See also ACTIVATE LOGICAL UNIT 
ACTLU response 4-17 


ACTLU_RQ_RCV_RECORD structure A-21 
referenced by 
BUILD_AND_SEND_ACTLU_RSP_NEG 4-57 
BUILD_AND_SEND_ACTLU_RSP_POS 4-58 
PROCESS_ACTLU_RQ 4-75 
PROCESS RECORD_FROM_NNM 4-50 
ACTLU_RSP_SEND_RECORD structure A-17 
referenced by 
BUILO_ANOD_SEND_ACTLU_RSP_NEG 4-57 
BUILO_AND_SEND_ACTLU_RSP_POS 4-58 
address 
See network address 
ADDRESS structure A-34%4 
referenced by 
BIND _SESSION_LIMIT_EXCEEDED 4-55 
BUILD_AND_SEND_PC_HS_CONNECT 4-65 
agent 
See sync point, roles, agent 
ALLOCATE_PROC procedure 5.1-11 
referenced by 
PS CONV 5.1-10 
ALLOCATE_RCB_PROC procedure 3-24 
referenced by 
PROCESS_PS_TO_RM_RECORD 3-21 
ALLOCATE_RCB structure A-25 
referenced by 
ALLOCATE_PROC 5.1-11 
ALLOCATE_RCB_ PROC 3-24 
CREATE_RCB 3-39 
TEST_FOR_FREE_FSP_SESSYON 3-65 
Already Verified indicator 
See conversation-level security, Already 
Verified indicator 
API 
See application program interface (API) 
application program interface (API) 2-4 
See also. protocol boundary 
closed 2-13 
open 2-13 
application transaction program 2-1 
See also transaction program 
asynchronous transfer 2-7, 2-38 
See also SNA Distribution Services (SNADS) 
ATTACH_CHECK procedure 3-25 
referenced by 
ATTACH _PROC 3-27 
ATTACH_ERROR_PROC procedure 5.0-10 
referenced by 
PS_INITIALIZE 5.0-6 
Attach FM header (FMH-5) 
See also FM header, type 5 (Attach) 
purpose of H-5 
ATTACH_HEADER structure A-13 
referenced by 
ATTACH_CHECK 3-25 
ATTACH _PROC 3-27 
GENERATE_RM_PS_INPUTS 6.1-31 
PROCESS_RU_DATA 6.1-34 
PS CREATION_PROC 3-47 
ATTACH_LENGTH_CHECK procedure 3-26 
referenced by 
ATTACH_CHECK 3-25 
ATTACH_PROC precedure 3-27 
referenced by 
PROCESS_HS_TO_RM_RECORD 3-19 
RM 3-18 
ATTACH_RECEIVED structure A-32 


Index | X-] 


X~-2 


referenced by 
ATTACH_PROC 3-27 
RCB_ALLOCATED_PROC 5.1-48 
ATTACH_SECURITY_CHECK procedure 3-29 
referenced by 
ATTACH CHECK 3~-25 
attaching transaction programs 2-38, 2-47 
autoactivation 
See session limits, automatic activation 
automatic session activation 
See session Limits, automatic activation 
availability of an LU 
for session initiation 4-9 
notification using NOTIFY(Vector Key 
X'0C') 4-14 


back-out 
See syne point, back-out 
Backed Out 
See sync point, commands, Backed Out 
base function set 2-12, 2-13 
CNOS functions 5.4-21 
control operator functions 5.4-20 
basic conversation 2-3, 2-13 
See also conversation 
state 5.1-6 
basic conversation message 2-15 
basic information unit (BIU) 2-15, 2-16; 
2-32 
Begin Bracket indicator (BBI) 
use 6.1-1, 6.1-4) 6.1-6, 6.1-9, 6.1-10; 
6.1-11, 6.1-12, 6.1-14 
Begin Chain indicator (BCI) 
use 6.1-8) 6.1-12, 6.1-13 
bid 
See bracket, bid 
BID_PROC procedure 3-30 
referenced by 
PROCESS_HS_TO_RM_RECORD 3-19 
BID_RSP_PROC procedure 3-32 
referenced by 
PROCESS_HS_TO_RM_RECORD 3-19 
BID_RSP structure A-14, A-28 
referenced by 
BID_PROC 3-30 
BID_RSP_PROC 3-32 
GENERATE_RM_PS_INPUTS 6.1-31 
SEND_RSP_TO_RM_OR_PS 6.1-39 
BID structure A-14 
referenced by 
BID_PROC 3-30 
GENERATE_RM_PS_INPUTS 6.1-31 
BID_WITH_ATTACH structure A-28 
referenced by 
BIDDER_PROC 3-34 
DFC_SEND_FROM_RM 6.1-20 
FIRST _SPEAKER_PROC 3-43 
SESSION_ACTIVATED_ALLOCATION 3-56 
BID_WITHOUT_ATTACH structure A-29 
referenced by 
BIDDER_PROC 3-34 
DFC_SEND_FROM_RM 6.1-20 
bidder 2-8, 2-35 
See also bracket, bidder 
See also contention loser 
BIDDER_PROC procedure 3-34 
referenced by 
GET_SESSION_PROC 3-45 
bidding 2-35, 3-5, 3-10 


See also bracket, bidding 
bidding with data 
See bracket, bidding 
BIND 2-8, 2-16) 2-36, E-5 
See also BIND SESSION 
BIND FAILURE (BINDF) 4-11, E-9 
BIND image 
derived from mode name 4-5 
in CINIT 4-9 
BIND negotiation 2-36 
BIND response 4-25 
BIND_RQ_ RCV_RECORD structure A-21 
referenced by 
BINO_RQ_STATE_ERROR 4-52 
BUTLD_ANOD_SEND_BIND_RSP_NEG 4-59 
BUILD_AND_SEND_BIND _RSP_POS 4-60 
FSM_STATUS 46-95 
INITIALIZE_LULU_CB_BIND 4-74 
PROCESS BIND _RQ 4-79 
PROCESS_RECORD_FROM_NNM 4-50 
BIND_RQ SEND_RECORD structure 4-17 
referenced by 
BUILD_AND_SEND_ BIND RQ 4-59 
BIND_RQ_STATE_ERROR procedure 6-52 
referenced by 
PROCESS_BIND_RQ 4-79 3 
BIND_RSP_RCV_RECORD structure A-22 
referenced by 
BIND_RSP_STATE_ERROR 4-53 
PROCESS _BIND_RSP 4-81 
PROCESS RECORD_FROM_NNM 4-50 
BIND_RSP_SEND_RECORD structure A-17 
referenced by | 
BUILD_ANO_SEND_BIND_RSP_NEG 4-59 
BUILD_AND_SEND_BINO_RSP_POS 4-60 
BIND_RSP_STATE_ERROR procedure 4-53 
referenced by 
PROCESS BIND RSP 4-81 
BIND SESSION (BIND) 4-19, E-5 
BIND_SESSION_LIMIT_EXCEEDED procedure 4-55 
referenced by 
- BIND_RQ_STATE_ERROR 4-52 
BINDF E-9 
See also BIND FAILURE 


binding of generic finite-state machines N-1 


BIS 2-16, 2-36, E-9 
See also BRACKET INITIATION STOPPED 
BIS (BRACKET INITIATION STOPPED) 6.1-14 
BIS_RACE_LOSER procedure 3-35 
referenced by . 
FSM_BIS_BIDDER 3-70 
BIS_REPLY_PROC procedure 3-35 
referenced by 
PROCESS_HS_TO_RM_RECORD 3~19 
BIS_ REPLY structure A~-14, A-29 
referenced by 
BIS_RACE_LOSER 3-35 
BIS_REPLY_PROC 3-35 
GENERATE_RM_PS_INPUTS 6.1-31 
SEND_BIS_REPLY 3-53 
BIS RQ_PROC procedure 3-36 
referenced by 
| PROCESS _HS_TO_RM_RECORD 3-19 
BIS_RQ structure A-14, A-29 
referenced by 
BIS_RQ_ PROC 3-36 
GENERATE_RM_PS_INPUTS 6.1-31 
SEND_BIS_RQ 3-54 
BIU 
See basic information unit (BIU) 
BIU structure A-34 
blanks 
See space (X'40') characters 
block chaining cryptography 6.2-5 
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block diagram representation 1-1 
block diagram, arrow and line conventions 
within 1-6 
blocking of message units 
See reblocking 
bracket 2-16, 2-35 
See also message units, session sequences 
bid 6.1-4, 6.1-9, 6.1-10, 6.1-14 
bidder 6.1-3, 6.1-9, 6.1-10, 6.1-15 
bidding 6.1-4, 6.1-9 
bracket termination rule 6.1-3, 6.1-4, 
6.1-9 
error conditions 6.1-10 
first on session 2-35 
first speaker 6.1-3, 6.1-9, 6.1-10 
initiation 6.1-9 
protocols 6.1-1, 6.1-9 
relationship to conversation 6.1-9 
RH indicators 6.1-9, 6.1-10 
BRACKET INITIATION STOPPED (BIS) 3-16, 
5.3-12, 6.1-2, 6.1-9, 6.1-10, 6.1-12, 
6.1-13, 6.1-14, E-9 
bracket state 2-35, 2-36 
bracket termination rule 
See bracket, bracket termination rule 
BUFFER_ELEMENT structure A-8 
referenced by 
ATTACH_ERROR_PROC 5.0-10 
DEQUEVE_FMH7_PROC 5.1-36 
GET_END_CHAIN_FROM_HS 5.1-37 
PERFORM_RECEIVE_ PROCESSING 5.1-39 
SEND_ERROR_PROC 5.1~-26 
TEST_FOR_POST_SATISFIED 5.1-58 
TEST_PROC 5.1-27 
WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 5.1-61 
WAIT_FOR_SEND_ERROR_DONE_PROC 5.1-62 
buffer record 2-14, 2-16, 2-31, 2-32 
buffering between LU component proc- 
esses 2-32 > 
BUILD_AND_SEND_ACT_SESS_RSP_NEG proce- 
dure 4-56 
referenced by 
FSM_STATUS 4-95 
PROCESS ACTIVATE_SESSION 4-77 
BUILD_AND_SEND_ACT_SESS_RSP_POS proce- 
dure 4-57 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SEND_ACTLU_RSP_NEG procedure 4-57 
referenced by 
PROCESS _ACTLU_RQ 4-78 
BUILD_AND_SEND_ACTLU_RSP_POS procedure 4-58 
referenced by 
PROCESS_ACTLU_RQ 4-78 
BUILD_AND_SEND_BIND_R@Q procedure 4-59 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_ SEND _BIND_RSP_NEG procedure 4-59 
referenced by 
FSM_STATUS 4-95 
PROCESS BIND RQ 4-79 
BUILD_AND_SEND_BIND_RSP_POS procedure 4-60 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SEND_BINDF_RQ procedure 4-60 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SEND_CINIT_RSP procedure 4-61 
referenced by 
FSM_STATUS 4-95 
PROCESS _CINIT_RQ 4-82 
BUILD_AND_SEND_DACTLU_RSP procedure 4-62 
referenced by 
PROCESS _DACTLU_RQ 4-86 


BUILD_AND_SEND_DEACTIVATE_SESS proce- 
dure 4-62 
referenced by 
FSM_STATUS 4-95 
BUILD_ANO_SEND_HIER_RESET_RSP procedure 4-63 
referenced by 
PROCESS HIERARCHICAL _RESET 4-87 
BUILD_AND_SEND_INIT_HS procedure 4-63 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SENO_INIT_RQ procedure 4-64 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SEND_PC_CONNECT procedure 4-64 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SEND_PC_HS_CONNECT procedure 4-65 
referenced by 
FSM_STATUS 4-95 
PROCESS_ACTLU_RQ 4-78 
BUILD_AND_SEND_PC_HS_DISCONNECT proce- 
dure 4-65 
referenced by 
CLEANUP_LU_LU_SESSION 4-72 
FSM_STATUS 4-95 
PROCESS DACTLU_RQ 4-86 
BUILD_AND_SEND_RSP_OR_LOG procedure 4-66 
referenced by 
FSM_STATUS 4-95 
PROCESS_CLEANUP_RQ 4-84 
PROCESS CTERM_RQ 4-85 
PROCESS_NOTIFY_RQ 4-89 
PROCESS _RECORD_FROM_HS 4-48 
BUILD_AND_SEND_SESS_ACTIVATED procedure 4-67 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SEND_SESS_DEACTIVATED proce- 
dure 4-67 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SEND_SESSEND_RQ procedure 4-68 
referenced by 
CLEANUP_LU_LU_SESSION 4-72 
BUILD_AND_SEND_ SESSST_R@ procedure 4-68 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SEND_TERM_RQ@ procedure 4-69 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SEND_UNBIND_RQ procedure 4-69 
referenced by 
FSM_STATUS 4-95 
BUILD_AND_SEND_UNBIND_RSP procedure 4-70 
referenced by 
FSM. STATUS 4-95 
PROCESS_UNBIND_RQ 4-91 
BUILD_AND_SEND_UNBINDF_RQ@ procedure 4-70 
referenced by 
FSM_STATUS 4-95 


CALL/RETURN procedure interaction 
CALL statement 
finite-state machines N-! 
input signal N-1 
next-state indicator N-1 
calling trees 
TC initialization calling tree 6.2-7 
TC RCV calling tree 6.2-7 
TC SEND calling tree 6.2-7 
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cascaded agent 
See syne point, roles, cascaded agent 
cascaded protocol 
See sync point, roles, cascaded agent 
category value, sense code 6-1 
See also sense data 
chain 2-16 
relationship to verbs 2-19 
chaining 
definite-response chain 6.1-8 
exception-response chain 6.1-8 
general description 6.1-1, 6.1-8 
RH indicators 6.1-8 
use in FM profiles 6.1-2, 6.1-16 
CHANGE_ACTION procedure 5.4-44 
referenced by 
LOCAL_SESSION_LIMIT_PROC 5.4-41 
PROCESS_SESSION_LIMIT_PROC 5.4-58 
RESET _SESSION_LIMIT PROC 5.4-34 
SOURCE_SESSION_LIMIT_PROC 5.4-46 
Change Direction indicator (CDI) 


Mode Name Not Recognized reply modi fi- 


er 5§.4-30 
Negotiated reply modifier 5.4-28 
reply modifier field 5.4-30 


change-number-of-sessions service transaction 


program 5.4-1, 5.4-5, 5.4-11, 5.4-21, 
5.4-22 

name 5.4-22, 5.4-27 

relationship to PS.COPR 5.4-1, 5.4-28 


CHANGE_SESSION_LIMIT_PROC procedure 5.4-35 


referenced by 
PS_COPR 5.4-32 
CHANGE_SESSION_LIMIT verb 5.4-6, 5.4-15, 
5.4-21 
processing by PS.COPR 5.4-29 
CHANGE_SESSIONS 5.4-8, 5. 4-24, 5.4-25, 
54-28 
CHANGE_SESSIONS_PROC procedure 3-37 
referenced by 
PROCESS PS_TO_RM_RECORD 3-21 


CHANGE_SESSIONS structure A-26 
use 6.1-4, 6.1-9, 6.1-10, 6.1-11, 6.1-12, referenced by 
6.1-14 CHANGE_ACTION 5.4-44¢ 
change number of sessions (CNOS) 2-38, CHANGE_SESSIONS PROC 3-37 
5.4-3, 5.4-5, H-12 CHECK _CNOS_COMMAND procedure 5.4-63 
See also presentation services for the referenced by 
control operator (PS.COPR) PROCESS SESSION_LIMIT_PROC 5.4-58 
command format H-12 CHECK_CNOS_REPLY procedure 5.4-56 
component relationship 5.4-6 referenced by 
source-LU services 5.4-25 SOURCE_SESSION_LIMIT_PROC 5.4~-46 
target-LU services 5.4-28 CHECK_FOR_BIS_REPLY procedure 3-38 
conversation 5.4-7 referenced by 
allocating 5.4-27 FSM_BIS BIDDER 3-70 
Attach processing 5.4-22 FSM_BIS_FSP 3-71 
basic conversation verbs used 5.4-9 CINIT E-9 
mode name 5.4-20, 5.4-27 See also CONTROL INITIATE 
error recovery CINIT response 4-10 
See error recovery, CNOS CINIT_RQ_STATE_ERROR procedure 4-71 
locking (LU,mode) entry 5.4-14, 5.4-30 referenced by 
message unit flows 5.4-10 PROCESS_CINIT_RQ 4-82 
privilege 5.4-24, 5.4-27 class of service 2-3, 4-5 
processes 5.4-i1 CLEAN UP SESSION (CLEANUP) 4-12, E-10 
concurrency 5.4-12 CLEANUP E~10 
race resolution See also CLEAN UP SESSION 
action race 5§.4-14 CLEANUP_LU_LU_SESSION procedure 4-72 
comand race 5.4-14 referenced by 
double command failure 5.4-15, 5.4-19 FSM_STATUS 4-95 
LU name comparison 5.4-19 CLOSE_ONE_REPLY procedure 5.4-65 
mo race 5.4-16 referenced by 
single command failure 5.4-16 NEGOTIATE_REPLY 5.4-64 
relationship to HS 5.4-12 | CNOS 
relationship to LNS 5.4-8 See change number of sessions (CNOS) 
relationship to RM 5.4-8) 5.4-28 CNOS service TP 


retry See change-number-of-sessions service 
See change number of sessions (CNOS), transaction program | 
race resolution, double command fail- commit 
ure See syne point 
See error recovery, CNOS commitment 
security See syne point 
See change number of sessions (CNOS), Commi tted 
privilege See sync point, commands, Committed 


transaction 5.4-9, 5.4-12 
Change Number of Sessions 6DS variable 5.4-7 
CNOS command 5.4-7, 5.4-27 
Close action 5.4-30 Compare States H~-14 
Set action 5.4-28, 5.4-29 See also syne point» commands, Compare 
CNOS reply 5.4-7, 5.4-27, 5.4-28 States 
See also Change Number of Sessions 6DS command format He 14 
variable, CNOS command COMPLETE_CONFIRM_PROC procedure 5.1-29 
Accepted reply modifier 5&.4-28 referenced by 
Command Race reply modifier 5.4-15, CONFIRM_PROC 5.1-12 
5.4-30 COMPLETE_DEALLOCATE_ABEND_PROC proce-~ 
Mode Name Closed reply modifi- dure 5.1-30 
er 5.4-29, 5.4-30 referenced by 


Common Subvector 
Product Identifier (X'1I') E-24 
Product Set ID (X'10') E~-24 
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DEALLOCATE_ABEND_PROC 5.1-32 
WAIT_FOR_SEND_ERROR_DONE_PROC 5.1-62 
COMPLETE_HS_ATTACH procedure 3-38 
referenced by 
ATTACH_PROC 3-27 
conditional bracket termination 
See bracket, bracket termination rule 
Conditional End Bracket indicator (CEBI) 
use 6.1-2, 6.1-4, 6.1-6, 6.1-9, 6.1-10, 
6.1-11, 6.1-14 
CONFIRM_PROC procedure 5,1-12 
referenced by 
PS CONV 5.1-10 
CONFIRMED_PROC procedure 5.1-14 
referenced by 
PS CONV 5.1-10 
CONFIRMED structure A-12, A-24 
referenced by 
CONFIRMED_PROC 5.1-14 
DFC_SEND_FROM_PS 6.1-19 
SEND_RSP_TO_RM_OR_PS 6.1-39 
CONNECT_RCB_AND_SCB procedure 3-39 
referenced by 
BID_RSP_PROC 3-32 
COMPLETE_HS_ATTACH 3-38 
FIRST_SPEAKER_PROC 3-43 
SESSION_ ACTIVATED ALLOCATION 3- 56 | 
TEST_FOR_FREE_FSP_SESSION 3-65 
contention loser 2-8, 2-35, 5.4-3) 5.4-4 
See also bidder 
See also bracket, bidder 
See also session, contention polarity 
contention winner 2-8, 2-35, 5.4-4 
See also bracket, first speaker 
See also first speaker 
See also session, contention polarity 
contention, bracket 
See bracket, protocols 
continuation bit in length prefix 2-14 
See also length prefix (LL) 
control component 
See service component 
CONTROL INITIATE (CINIT) 4-9, E-9 
control mode 
delayed request 6.1-16 
delayed response 6.1-16 
immediate request 6.1-1, 6.1-2, 6.1-8; 
6.1-16 
immediate response 6.1-1, 6.1-2, 6.1-8, 
6.1-16 
control operator 2-2, 2-3, 2-38, 5.4-1, 
§.4-22 
See also control-operator transaction pro- 
gram 
control-operator transaction program 2-3, 
2-36, 2-38) 2-46, 5.4-1, 5.4-5, 5.4-7, 
5.4-11, 5.4-20, 5.4-21, 5.4-22 
relationship to PS.COPR 5.4-1, 5.4-25 
control-operator verbs 2-3, 2-8) 2-38, 5.4-2 
CNOS 5.4-6, 5.4-21 
See also change number of sessions 
(CNOS } 
distributed function 5.4-3, 5.4-5, 5.4-6 
local fumction 5.4-3, 5.4-5, 5.4-6, 
5.4-24 
local session control 5.4-6 
LU definition 5.4-5, 5.4-20 
processing by PS.COPR 5.4-24 
control point (CP) 2-4, 2-6, 2-8, 2-11, 
2-16, 2-36, 2-42, 4-2 
See also PNCP (peripheral node control 
point) 
See also SSCP (system services control 
point) 


relationship to LU 2-28, 2-37 
CONTROL TERMINATE (CTERM) 4-12, E-10 
Control Vector 
Control Vector Keys Not Recognized E-22 
Local Form Session Identifier E-22 
LU-LU Session Services Capabilities E-21 
Mode/ Class-of-Service/ 
Virtual-Route-Identifier-List E-21 
Network-Qualified Address Pair E-21 
SSCP-LU Session Capabilities E~-20 
VR-ER Mapping Data E-22 
Control Vector Keys Not Recognized Control 
Vector E-22 
conversation 2-1, 2-3, 6.1-9 
See also bracket 
allocation to transaction program 2-35, 
3-4, 5.1-6 
basic 
See basic conversation 
deallocation 2~35 
mapped 
See mapped conversation 
relationship to bracket 6.1-9 
termination 3-12 
conversation correlator 5§.3-3, 5.3-18 
conversation exchange 2-15 
See also message wits, conversation 
sequences 
conversation failure 
See errors, conversation failure | 
CONVERSATION_FAILURE PROC procedure 5§.1-31 
referenced by 
GET_END_CHAIN_FROM_HS 5.1-37 
PROCESS_RM_OR_HS_TO_PS_RECORDS 5.1-47 
PS_PROTOCOL_ERROR 5.0-15 
WAIT _FOR_CONFIRMED_PROC 5.1-59 
WAIT _FOR_RM_REPLY 5.1-60 
WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 5.1-61 
CONVERSATION_FAILURE structure A-32 
referenced by 
CONVERSATION_FAILURE_PROC 5.1-31 
PS_PROTOCOL_ERROR 5.0-15 
RECETVE_RM_OR_HS_TO_PS_RECORD 5.1~-51 
SEND_DATA_PROC 5.1-24 
SESSION DEACTIVATED_PROC 3-58 
conversation-level security 2-10, 2-11, 
2-34, 2-36, 2-37, 3-2, 3-9 
Access Security Information subfields H-7 
already verified Attach 2-1] 
Already Verified indicator 2-11, 2-34 
downgrade 5.1-4, 5.1-7 
password 2-11, 2-37 
profile 2-11, 5.0-3 
user ID 2-11, 5.0-3 
conversation message 2-15, 2-16 
See also basic conversation message 
See also message units 
conversation resource 2-35, 2-42 
See also conversation 
correlation 
See request/response correlation 
correlation entries 
See request/response correlation 
cos 
See class of service 
cP 
See control point (CP) 
CP_ID structure A-2 
referenced by 
ACTIVATE_SESSION_ERROR 4-51 
INITIALIZE _LULU_CB_ACT_SESS 4-73 
PROCESS _ACTIVATE_SESSION 4-77 
CP-LU session 2-16, 2-36, 2-45 
See also session 
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CPLU_CAPABILITY structure 2-42 
CPLU_CB structure A-1 
referenced by 
INITIALIZE _LULU_CB_CINIT 4-75 
PROCESS ACTLU_RQ 4-78 
PROCESS DACTLU_RQ 4-86 
PROCESS HIERARCHICAL_RESET 4-87 
PROCESS _SESSION_ROUTE_INOP 4-90 
CREATE_RCB precedure 3-39 
referenced by 
ALLOCATE_RCB_PROC 3-24 
TEST_FOR_FREE_FSP_SESSION 3-65 
CREATE_SCB precedure 3-40 
referenced by 
SUCCESSFUL_SESSION_ACTIVATION 3-63 
CRV E-10 
See also CRYPTOGRAPHY VERIFICATION 
See also CRYPTOGRAPHY VERIFICATION (CRV) 
CRV_RQ_RU structure A-33 
cryptography 6.2-1, 6.2-2, 6.2-3, 6.2-4, 
6.2-5 
See also session cryptography 
block chaining 6.2-5 
CRV 6.2-2, 6.2-3 
initial chaining value 6.2-2, 6.2-3 
session cryptography key 6.2-2 
session seed 6.2-2 
test value 6.2-2 
Data Encryption Standard (DES) 6.2-5 
initial chaining value 6.2-2, 6.2-3 
initialization 6.2-2 
parameters in BIND 4-23 
session cryptography key 6.2-2, 6.2-5 
session key distribution 6.2-3 
session-level 4-23 
session seed 6.2-2, 6.2-5 
session seed distribution 6.2-3 
cryptography key, session 
in BIND image : 
enciphered under SLU master key 4-10 
in CINIT 
enciphered under PLU master key 4-10 
CRYPTOGRAPHY VERIFICATION (CRV) 6.2-2, E-10 
session cryptography key 6.2-2 
session seed 6.2-2 
test value 6.2-2 
CTERM E-10 
See also CONTROL TERMINATE 
CTERM_DEACTIVATE_SESSION_PROC procedure 3-40 
referenced by 
PROCESS_LNS_TO_RM_RECORD 3-20 
CTERM_DEACTIVATE_SESSION structure A-20 
referenced by 
BUILD_AND_SEND_DEACTIVATE_SESS 4-62 
CTERM_DEACTIVATE_SESSION_PROC 3-40 
current bracket ID 
See current bracket sequence number 
current bracket sequence number 6.1-5, 
6.1-6, 6.1-7 


Lo | 


DACTLU E-1i1 
See also DEACTIVATE LOGICAL UNIT 
DACTLU_LRQ_RCV_RECORD structure A-22 
referenced by 
BUILD _AND_SEND_DACTLU_RSP 4-62 
PROCESS DACTLU_RQ 4-86 
PROCESS _RECORD_FROM_NNM 4-50 
DACTLU_RSP_SENO_RECORD structure A-17 
referenced by 


BUILD_AND_SEND_DACTLU_RSP 4-62 
data base resources 2-4, 2-39 
consistency of updates 
See sync point, data base update con- 
sistency 
Data Eneryption Standard (DES) 6.2-5 
data flow control (DFC) 
BIS 6.13-2, 6.1-9, 6.1-10, 6.1-12, 6.1-13, 
6.1~-14 
initialization 6.1-1 
LUSTAT 6.1-2, 6.1-4 6.3-10, 6.1-12, 
6.1-13, 6.1-14 
protocol boundaries 6.1-3, 6.1-17 
request formats 6.1-12, 6.1-13 
response formats 
RTR 6.1-2, 6.1-4, 6.1-5) 6.1-7) 6.1-9,5 
6.1-10, 6.1-12, 6.1-13, 6.1-15 
SIG 6.1-2) 6.1-4%, 6.1-5) 6.1-6, 6.1-7, 
6.1-12, 6.1-13, 6.1-15 
structure 6.1-1 
data record 2-14, 2-31, 2-39 
data shipping 
data structures 2-42 
system definition 2-42 
data traffic 
activation 6.2-1 
deactivation 6.2-1 
data traffic protocols 
CRV 6.2-2 
session cryptography key 6.2-2 
session seed 6.2-2 
test value 6.2-2 
session cryptography key 6.2-2 
session seed 6.2-2 
DEACTIVATE_FREE_SESSIONS procedure 3-41 
referenced by 
CHANGE_SESSIONS_PROC 3-37 
DEACTIVATE LOGICAL UNIT (DACTLU) 4-19, E-11 
DEACTIVATE_PENDING_SESSIONS procedure 3-41 
referenced by 
CHANGE_SESSIONS PROC 3-37 
DEACTIVATE_SESSION_PROC procedure 5.4-37 
referenced by 
PS COPR 5.4-32 
DEACTIVATE_SESSION structure A-31 
referenced by 
BUILD_AND_SEND_TERM_RQ 4-69 
FSM_STATUS 4-95 
PROCESS_DEACTIVATE_SESSION 4-87 
PROCESS_RECORD_FROM_RM 4-48 
SEND_DEACTIVATE_SESSION 3-55 
DEACTIVATE_SESSION verb 5.4-6, 5.4-20 
processing by PS.COPR 5.4-25 
deactivation, session 
CP-LU 4-2, 4-19 
LU-LU 4-3, 4-28 
deadlock 6.2-6 
DEALLOCATE_ABEND_PROC procedure 5.1-32 
referenced by 
DEALLOCATE_PROC 5.1-15 
DEALLOCATE_CONFIRM_PROC procedure 5.1-33 
referenced by 
DEALLOCATE_PROC 5.1-15 
DEALLOCATE_FLUSH_PROC procedure 5.1-35 
referenced by 
DEALLOCATE_PROC 5.1-15 
DEALLOCATE_PROC procecure §.1-15 
referenced by 
PS_CONV 5.1-10 
DEALLOCATE_RCB structure A-26 
referenced by 
DEALLOCATE_PROC 5.1-15 
FLUSH_PROC 5.1~-17 
PROCESS _PS_TO_RM_RECORD 3-21 
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DEALLOCATION_CLEANUP_PROC procedure 5.0-13 
referenced by 
ACTIVATE_SESSION_PROC 5.4~-36 
ALLOCATE_PROC 5.1-11 
ATTACH_ERROR_PROC 5.0-10 
CHANGE_SESSION_LIMIT_PROC 5.4-35 
CONFIRM PROC 5.1-12 
DEACTIVATE_SESSION_PROC 5.4-37 
DEALLOCATE_CONFIRM_PROC 5.1-33 
DEALLOCATE_FLUSH_PROC 5.1-35 
DEALLOCATE_PROC 5.1-15 
FSM_CONVERSATION 5.1-63 
INITIALIZE_SESSION_LIMIT_PROC 5.4-33 
LOCAL_VERB_PARAMETER_CHECK 5.4-42 
MC_ALLOCTATE_PROC 5.2-20 
PREPARE_TO_RECEIVE_PROC 5.1-19 
PROCESS_SESSION_LIMIT_PROC 5.4-58 
PS_INITIALIZE 5.0-6 
PS_VERB_ROUTER 5.0-11 
RECEIVE _PIP_FIELD_FROM_HS 5.0-7 
RESET_SESSION_LIMIT_PROC 5.4-34 
SEND_DATA_PROC 5.1-24 
SNASVCMG_VERB_PARAMETER_CHECK 5.4-43 
VERB_PARAMETER_CHECK 5.4-48 
WAIT_PROC 5.0-13 
deciphering 6.2-1, 6.2-4, 6.2-5 
block chaining 6.2-5 
CRV 6.2-2 
session cryptography key 6.2-2 
session seed 6.2-2 
test value 6.2-2 
Data Encryption Standard (DES) 6.2-5 
session cryptography key 6.2-2, 6.2-5 
session seed 6.2-2 
DEFINE PROC procedure 5.4-38 
referenced by 
PS COPR 5.4~-32 
definite-response chain 
See chaining, definite-response chain 
delayed request mode 
See control mode, delayed request 
delayed response mode 
See control mode, delayed response 
DELETE PROC procedure 5.4-40 
referenced by 
PS _COPR 5.4-32 
DEQUEVE_FMH7_PROC procedure 5.1-36 
referenced by 
CONFIRM_PROC 5.1-12 
DEALLOCATE_CONFIRM_PROC 5.1-33 
PREPARE_TO_RECEIVE_CONFIRM_PROC 5.1-41 
RECEIVE_AND_WAIT_PROC 5.1-20 
RECEIVE_IMMEDIATE_PROC 5.1-22 
SEND_DATA_PROC 5.1-24 
SEND_ERROR_IN_SEND_STATE 5.1-55 
TEST_PROC 5.1-27 
WAIT_FOR_CONFIRMED_PROC 5.1-59 
DEQUEVE_WAITING REQUEST procedure 3-42 
referenced by 
FREE_SESSION_PROC 3-44 
RTR_RSP_PROC 3-51 
DES algorithm 4-5 
destination LU (DLU) 4-4 
destination transaction program 2-7 
DFC_INITIALIZE procedure 6.1-18 
referenced by 
HS 6.0-3 
DFC_RCV_FSMS procedure 6.1-24 
referenced by 
DFC_RCV 6.1-23 
DFC_RCV procedure 6.1-23 
referenced by 
TC.RCV 6.2-15 
DFC_SEND_FROM_LNS procedure 6.1-22 


referenced by 
PROCESS _CP_LU_SESSION 6.0-5 
DFC_SEND_FROM_PS procedure 6.1-19 
referenced by 
PROCESS_LU_LU_SESSION 6.0-4 
DFC_SEND_FROM_RM procedure 6.1-20 
referenced by 
PROCESS LU_LU_ SESSION 6.0-4 
DFC_SEND_FSMS procedure 6.1-25 
referenced by 
DFC_SEND_FROM_PS 6.1-19 
DFC_SEND_FROM_RM 6.1-20 
SEND_BIU 6.1-37 
SEND_RSP_BIU 6.1-38 
DIA 
See Document Interchange Architecture 
(DIA) 
DISPLAY_PROC procedure 5.4-39 
referenced by 
PS_COPR 5.4-32 
distributed operator control 2-3 
See also control-operator verbs, distrib- 
uted function 
distributed processing 2-1 
distributed transaction 2-1, 2-38, 2-45 
CNOS 5.4-9 
distributed transaction program 
See logical unit of work (LUN), distrib- 
uted 
distribution service unit (DSU) 2-38 
oDLU 
See destination LU (DLU) 
Document Interchange Architecture (DIA) 2-38 
document interchange services 
See Document Interchange Architecture 
(DIA) 
domain, definition of 1-5 
drain 2-36, 2-47 
drain of session allocation requests 3-16; 
5.4-4, 5.46-8, 5.4-21, 5.4-25, 5.4-30 
negotiation by CNOS 5.4-30 
DSU. 
See distribution service unit (DSU) 


ECHO TEST (CECHOTEST) 4-31, E-1} 
ECHOTEST E-I! 
See also ECHO TEST 
EDI 
See Enciphered Data indicator (EDI) 
Emulated Product Identifier (X'O1') Product 
Identifier Subfield E~-25 
enciphered data 4-27 
See also LU-LU verification 
See also session-level security, enci- 
phered data 
Enciphered Data indicator (EDI) 6.2-5 
Enciphered Data Structured Data Sub- 
field E-17 
ENCIPHERED_RD2 structure A-30 
referenced by 
DFC_SEND_FROM_RM 6.1-20 
SUCCESSFUL_SESSION_ACTIVATION 3-63 
enciphering 6.2-1, 6.2-4, 6.2-5 
block chaining 6.2-5 
CRV 6.2-2 
session cryptography key 6.2-2 
session seed 6.2-2 
test value 6.2-2 
Data Encryption Standard (DES) 6.2-5 
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X-8 


session cryptography key 6.2-2, 6.2-5 
session seed 6.2-2 
End Chain indicator (ECT) 
use 6.1-8, 6.1-11 
end of conversation message 2-15, 2-20, 
2-31, 2-32 
ERP (error recovery procedure) 
session activation and deactivation 4-34 
type of RSPCACTLU) 4-17 
error category 
See sense data 
ERROR_DATA_STRUCTURE structure 5.2-48 
referenced by 
PROCESS ERROR_DATA 5.2-43 
RCVD_SVC_ERROR_PURGING 5.2-42 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC 5.2-41 
SEND_SVC_ERROR_PURGING 5.2-45 
Error Description FM header (FMH-7) H-5 
See also FM header, type 7 (Error 
Description) 
error recovery 
See also errors 
CNOS 5.4-27, 5.4-30 
conversation failure 5.4-20, 5.4-27 
protocol violation 5.4-30 
unrecognized command parameters 5.4-30 
confirmation 2-12, 2-15 
control operator 2-12 
conversation deallocation 2-12 
distributed 
See sync point 
LU 2-12 
program 2-12, 2-15 
session deactivation 2-12 
sync point 
See sync point 
transaction program 2-12 
ERROR_TYPE structure 4-101 
referenced by 
ACTIVATE_SESSION_ERROR 4-51 
BUILD” AND_SEND_ACT_SESS_RSP_NEG 4-56 
PROCESS_ACTIVATE_SESSION 4-77 
errors e-ll 
See also error recovery 
See also errors and failures 
application-detected 2-11 
conversation failure 2-12, 2-36, 5.1-9 
local resource 2-11 
LU failure 2-12, 2-42 
program failure 2-11 
protocol 5.1-9 
session failure 2-12 
system recoverable 2-11 
errors and failures 5.3-1, 5.3-19, 5.3-24, 
5.3-25, 5.3-30, 5.3-31, 5.3-32, 5.3-33, 
5.3-41 
application errors 5.3-1 
conversation failures 5.3-1, 5.3-2; 
5.3-18, 5.3-19, 5.3-22, 5.3-32 
local resource failures 5.3-1 
LU failures 5.3-1, 5.3-2, 5.3-20 
program failures 5.3-1, 5.3-2 
recoverable system errors 5.3-1 
errors during sync point 
See sync point, errors during syne point 


-exception-response chain 


See chaining, exception-response chain 
Exchange Log Name 4H-13 
- See also sync point, commands, Exchange 
Log Name 
command format H-13 
expedited flow | 
in contrast to normal flow 6.2-4, 6.2-5 
TO 6.2-1) 6.2-4, 6.2-5 


EXR CEXCEPTION REQUEST) 
sunse data included with 6-1 


a 


failures 
See errors and failures 
FI 
See Format indicator (FI) 
files 
See sync point, local resources 
finite-state machine (FSM), basic notion 
of 1-1 
finite-state machines 
binding N-! 
call N-I 
generic finite-state machines N-1 
initialization N-1 
no-op finite-state machines N-1 
state N-! 
state check N-! 
state name N-] 
state test N-1 
state transition N-1 
first speaker 2-8, 2-35 
See also bracket, first speaker 
See also contention winner 
FIRST_SPEAKER_PROC procedure 3-43 
referenced by 
GET_SESSION_PROC 3-45 
flip-flop, half-duplex 
See send/receive mode, half-duplex 
flip-flop (HDX-FF) 
flow sequences 
basic conversation 2-50 
external protocol boundaries 2-19 
application-detected error cases 2-25 
error-free cases 2-20 
REQUEST_TO_SEND case 2-25 
internal protocol boundaries 2-50 
session activation and deactivation 2-52, 
2-54 
FLUSH_PROC procedure 5.1-17 
referenced by 
PS_ CONV 5.1-10 
FM (function management ) 
profiles F-1 
Usage field F-1 
FM header 2-15, 2-16, 2-40 
relationship to verbs 2-19 
type 12 (Security) 2-10, 2-15, 2-35, 
2-37, 3-14, 6.1-3, 6.1-4 
type 5 (Attach) 2-11, 2-15, 2-32, 2-34, 
2-35, 3-2, 3-9, 5.0-3, 5.1-7, 5.3-12, 
6.1-3, 6.1-4 
type 7 (Error Description) 2-15, 5.1-7, 
5.3-6, 5.3-7, 6.1-3, 6.1-45 6.1-7 
use in FM profile 19 6.1-3 
FM header 12: Security H-9 
FM header 5: Attach H-6 
FM header 7: Error Description H-8 
FM headers 
using H-4 
FM profile 
See also profiles 
in BIND 4-20 
FM profile 0 6.1-1, 6.1-16 
FM profile 19 6.1-1, 6.1-2, 6.1-4, 6.1-8, 
6.1-14 
FM profile 6 6.1-1, 6.1-16 
FM Usage field F-1 
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in BIND 4-20 FREE_SESSION_PROC 3-44 


FMH value in RH PROCESS _HS_TO_RM_RECORD 3-19 
use in chains H-4 RM_DEACTIVATE_SESSION PROC 3-49 
FMH-12 RTR_RSP_PROC 3-51 
See also FM header, type 12 (Security) SEND_BIS 3-53 
format H-9 SEND_BIS_REPLY 3-53 
purpose of H-5 SEND_BIS_RQ 3-54 
FMH-5 SHOULD_SEND_BIS 3-62 
See also FM header, type 5 (Attach) FSM_BSM_FMP19 6.1-43 
format H-6 FSM_BSM_FMP19 FSM 
purpose of H-5 referenced by 
FiMH~-7 DFC_LINITIALIZE 6.1-16 
See also FM header, type 7 (Error DFC_SEND_FROM_RM 6.1-20 
Description) FSM_CHAIN_SEND_FMP19 6.1-46 
format H-8 GENERATE_RM_PS_INPUTS 6.1-3} 
purpose of H-5 OK_TO_LREPLY 6.1-33 
Forget PROCESS_LU_LU_ SESSION 6.0-4 
See syne point, commands, Forget PROCESS_RU_DATA 6.1-34 
formal description, definition of 1-1! RCV_STATE_ERROR 6.1-36 
FORMAT_ERROR_EXP_RSP procedure 6.1-27 SEND_RSP_TO_RM_OR_PS 6.1-39 
referenced by STRAY_RSP 6.1-41 
FORMAT_ERROR 6.1-26 TRY_TO_RCV_SIGNAL 6.1-22 
FORMAT_ERROR_NORM_RSP procedure 6.1-27 FSM_CHAIN RCV_FMP19 6.1-44 
referenced by FSM_CHAIN_RCV_FMP19 FSM 
FORMAT_ERROR 6.1~26 referenced by 
FORMAT_ERROR procedure 6.1-26 DFC_INITIALIZE 6.1-18 
referenced by DFC_RCV_FSMS 6.1-24 
DFC_RCV 6.1-23 DFC_SEND_FROM_PS 6.1-19 
FORMAT_ERROR_RQ DFC procedure 6.1-28 DFC_SEND_FSMS 6.1-25 
referenced by OK_TO_REPLY 6.1-33 
FORMAT_ERROR 6.1-26 RCV_STATE_ERROR 6.1-36 
FORMAT_ERROR_RQ_FMD procedure 6.1-29 SEND_RSP_BIU 6.1-38 
referenced by UPDATE_FSMS 6.1-42 
FORMNAT_ERROR 6.1~-26 FSM_CHAIN_SEND_FMPI19 6.1-46 
FORMAT_ERROR_RQ_DFC 6.1-28 FSM_CHAIN_SEND_FMP1I9 FSM 
FORMAT_ERROR_SSCP_LU procedure 6.1-30 referenced by 
referenced by DFC_INITIALIZE 6.1-18 
DFC_RCV 6.1-23 DFC_RCV_FSMS 6.1-24 
Format indicator (FI) DFC_SEND_FSMS 6.1-25 
of RH H-4 OK_TO_LREPLY 6.1-33 
use 6.1-4 PROCESS_LU_LU_SESSION 6.0-4 
Format of an Error Data 60S variable H-18 RCV_STATE_ERROR 6.1~-36 
Format of Error Log GDS Variable H-19 UPDATE_FSMS 6.1-42 
FREE_SESSION_PROC procedure 3-44 FSM_CONVERSATION 5.1-63 
referenced by FSM_CONVERSATION FSM 
PROCESS_HS_TO_RM_RECORD 3-19 referenced by 
FREE_SESSION structure A-15 | COMPLETE_CONFIRM_PROC 5.1~-29 
referenced by COMPLETE_DEALLOCATE_ABEND_ PROC 5.1-30 
FREE_SESSION_PROC 3-44 CONFIRM_PROC 5.1-12 
FSM_CHAIN_RCV_FMP19 6.1-44 CONFIRMED_PROC 5.1~-14 
FSM_CHAIN_SEND_FMP19 6.1-46 DEALLOCATE_ABEND_PROC 5.1-32 
GENERATE_RM_PS_INPUTS 6.1-31 DEALLOCATE_CONFIRM_PROC §.1-33 
FSM_BIS_BIDDER 3-70 DEALLOCATE_FLUSH_PROC 5.1~-35 
FSM_BIS_ BIDDER FSM DEALLOCATE_PROC 5.1-15 
referenced by FLUSH_PROC 5.1-17 
BID_PROC 3-30 GET_ATTRIBUTES_PROC 5.1-18 
BIS_REPLY_PROC 3-35 PERFORM_RECEIVE PROCESSING 5.1-39 
BIS_RQ_PROC 3-36 POST_ON_RECEIPT_PROC 5.1-18 
CREATE_SCB 3-40 PREPARE_TO_RECEIVE CONFIRM_PROC 5.1-41 
FREE_SESSION_PROC 3-44 PREPARE _TO_RECEIVE_ FLUSH PROC 5.1-43 
PROCESS_HS_TO_RM_RECORD 3-19 PREPARE_TO_RECEIVE PROC 5.1-19 
RM_DEACTIVATE_SESSION_PROC 3-49 PROCESS FMH7_PROC 5.1-46 
RTR_RSP_PROC 3-51 PROCESS_RM_OR_HS_TO_PS_RECORDS 5.1-47 
SEND_BIS 3-53 RCB_ALLOCATED_PROC 5.1-48 
SEND_BIS REPLY 3-53 RECEIVE_ANO_WAIT_PROC 5.1-20 
SEND_BIS_RQ 3-54 RECEIVE_IMMEDIATE_PROC 5,1-22 
SHOULD_SEND_BIS 3-62 REQUEST_TO_SEND_PROC 5.1-23 
FSM_BIS FSP 3-71 | SEND_DATA_PROC 5.1~-24 
FSM_BIS_FSP FSM SEND_ERROR_DONE_PROC 5.1-53 
referenced by SEND_ERROR_IN_RECEIVE STATE 5.1-546 
BID_PROC 4-30 SEND_ERROR_IN_SEND_STATE 5.1-55 
BIS_REPLY_PROC 3-35 SEND_ERROR_PROC 5.1-26 
BIS_RQ_ PROC 3-36 SET_FMH7_RC §.1-57 
CREATE_SCB 3-49 TEST_PROC 5.1-27 


Index X-9 . 


X-10 


WAIT_FOR_CONFIRMED_PROC 5.1-59 
WAIT_FOR_SEND_ERROR_DONE_PROC 5. 1-62 


FSM_ERROR _OR_ FAILURE 5. 1-65 
FSM_ ERROR_ “OR, FAILURE FSM 
referenced by 


COMPLETE_CONFIRM_PROC 5.1-29 
COMPLETE_DEALLOCATE_ABEND_PROC 5.1-30 
CONFIRM_PROC 5.1-12 

CONFIRMED PROC 5.1-14 
CONVERSATION_FAILURE_PROC 5.1-31 
DEALLOCATE_ABEND_PROC 5.1-32 
DEALLOCATE_CONFIRM_PROC 5.1-33 
DEALLOCATE_FLUSH_PROC 5.1-35 
FLUSH_PROC 5.1-17 

FSM_CONVERSATION 5.1-63 
OBTAIN_SESSION_PROC 5.1-38 
PERFORM_RECEIVE_PROCESSING 5.1-39 
PREPARE_TO_RECEIVE_CONFIRM_PROC 5.1-41 
PREPARE_TO_RECEIVE_FLUSH_PROC 5.1-43 


PROCESS RM_OR_HS_ TO_ PS _RECORDS 5.1-47 


RCB_ALLOCATED_PROC 5.1-48 
RECEIVE _AND_WAIT_PROC 5.1-20 
RECEIVE _IMMEDIATE_PROC 5.1-22 


SEND_DATA_BUFFER_ MANAGEMENT 5.1~-51 


SEND_DATA_PROC 5.1-24 
SEND_ERROR_IN_SEND STATE 5.1-55 
SEND_ERROR_PROC 5.1-26 
SET_FMH7_RC 5.1-57 

TEST_PROC 5.1-27 
WAIT_FOR_CONFIRMED_PROC 5.1-59 


WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 5.1-61 
WAIT_FOR_SEND_ERROR_DONE_PROC 5.1-62 


FSM_IMMEDIATE_RQ_MODE_RCV 6.1-48 
FSM_IMMEDIATE_ RQ MODE_RCV FSM 
referenced by 
DFC_INITIALIZE 6.1-18 
DFC_RCV 6.1-23 
DFC_SEND_FROM_LNS 6.1-22 
STATE_ERROR_SSCP_LU 6.1-40 
FSM_IMMEDIATE_RQ MODE_SEND 6.1-48 
FSM_IMMEDIATE_RQ_MODE_SEND FSM 
referenced by 
DFC_INITIALIZE 6.1-18 
DFC_RCV 6.1-23 
DFC_SEND_FROM_LNS 6.1-22 
PROCESS_CP_LU_SESSION 6.0-5 
STATE_ERROR_SSCP_LU 6.1-40 
FSM_PAC_RQ.RCV 6.2-21 
FSM_PAC_RQ_RCV FSM 
referenced by 
TC.DEQUEUE_PAC 6.2-18 
TC.INITIALIZE 6.2-8 
TC.RCV_NORM_RQ 6.2-17 
TC.SEND 6.2-13 
TC. TRY_TO_SEND_IPR 6.2-19 
FSM_PAC_RQ_SEND 6.2-20 
FSM_PAC_RQ_SEND FSM 
referenced by 
TC .DEQUEUE_PAC 6.2-18 
TC.INITIALIZE 6.2-8 
TC.SEND 6.2-13 
FSM_POST 5.1-66 
FSM_POST FSM 
referenced by 


CONVERSATION_FAILURE_PROC 5.1~31 


DEQUEVE_FMH7_ PROC 5.1-36 


PERFORM_RECEIVE_PROCESSING 5.1-39 


POST_AND_WAIT_PROC 5.1-40 
POST_ON_RECEIPT_PROC 5.1-18 


PROCESS RM_OR_HS_TO_PS_RECORDS 5§.1-47 


TEST_FOR_POST_SATISFIED 5.1-58 
TEST_PROC 5.1-27 

FSM_QRI_CHAIN_RCV_FMP19 6.1-49 

FSM_QRI_CHAIN_RCV_FMP19 FSM 
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referenced by 


DFC_INITIALIZE 6.1-18 
RCV_STATE_ERROR 6.1-36 
UPDATE_FSMS 6.1-42 


FSM_RCB_STATUS_BIDDER 3-72 
FSM_RCB_STATUS_BIDDER FSM 
referenced by 


BID_RSP_PROC 3-32 

BIDDER_PROC 3-34 

PS CREATION_PROC 3-47 
SESSION_ACTIVATED_ALLOCATION 3-56 
SESSION DEACTIVATED_PROC 3-58 
SET_RCB_AND_SCB_FIELDS 3-61 


FSM_RCB_STATUS_FSP 3-73 
FSM_RCB_STATUS_FSP FSM 
referenced by 


BID_RSP_PROC 3-32 

BIDDER_PROC 3-34 
PS_CREATION_PROC 3-47 

SESSION | ACTIVATED ALLOCATION 3-56 
SESSION_ DEACTIVATED. PROC 3-58 
SET_RCB_ANO_SCB_FIELDS 3-61 


FSM_RCV_PURGE_FMPI9 6.1-50 
FSM_RCV_PURGE_FMP19 FSM 
referenced by 


DFC_INITIALIZE 6.1-18 
DFC_RCV_FSMS 6.1-24 
GENERATE_RM_PS_INPUTS 6.1-31 
UPDATE_FSMS 6.1-42 


FSM_SCB_STATUS_BIDDER 3-68 
FSM_SCB_STATUS_BIDDER FSM 
referenced by 


ATTACH_PROC 3-27 

BID PROC 3-30 

COMPLETE_HS_ATTACH 3-38 
CREATE_SCB 3-40 

FREE_SESSION PROC 3-44 
SECURITY_PROC 3-52 

SESSION _DEACTIVATED_PROC 3-58 
SET_RCB_AND_SCB_FIELDS 3-61 
SUCCESSFUL_SESSION_ACTIVATION 3-63 


FSM_SCB_STATUS_FSP 3-69 
FSM_SCB_STATUS_FSP FSM 
referenced by 


ATTACH_PROC 3-27 
BID_PROC 3-30 


COMPLETE_HS_ATTACH 3-38 


CREATE_SCB 3~40 
FREE_SESSION PROC 3-44 


SECURITY_ PROC 3-52 
SESSION_ DEACTIVATED_ PROC 3-58 


SET_RCB_AND_SCB_ FIELDS 3-61 


SUCCESSFUL_SESSION_ ACTIVATION 3-63 
FSM_STATUS 4-94 
FSM_STATUS FSM 
referenced by 
BUILD_AND_SEND_ACTLU_RSP_POS 4-58 


PROCESS_ABORT_HS 4-77 
PROCESS_ACTIVATE_SESSION 4-77 
PROCESS_BIND_RQ 4-79 

PROCESS _BIND_RSP 4~81 

PROCESS CINIT_RQ 4-82 
PROCESS_CLEANUP_RQ 4-84 

PROCESS _CTERM_RQ 4-85 

PROCESS _DACTLU_RQ 4-86 

PROCESS _DEACTIVATE_SESSION 4-87 
PROCESS HIERARCHICAL_RESET 4-87 
PROCESS INIT_HS_RSP 4-88 
PROCESS_INIT_SELF_RSP 4-88 
PROCESS _NOTIFY_R@ 4-89 

PROCESS _PC_CONNECT_RSP 4-90 
PROCESS _SESSION_ROUTE_INOP 4-90 
PROCESS _UNBIND_RQ 4-91 

PROCESS UNBIND_RSP 4-92 


full-duplex send/receive mode 

See send/receive mode, full-chplex (FDX) 
fully qualified LU name 

See LU name, fully qualified 
fully qualified netvnork name 4-5 
Fully Qualified PLU Network Name Structured 
Data Subfield €E-16 
Fully Qualified SLU Network Name Structured 
Data Subfield E-16 
fumction management (FM) profiles F-1 
function management header 

See FM header and FMH 
function shipping 

See sync point, function shipping 

resource 

See resource, function-shipped 


Ls 


60S 
See general data strean 
See general data stream variable 
60S header 
See general data stream header 
GDS ID 
See general data stream variable identifi- 
er 
6DS variable 
See general data stream variable 
general data stream I-1! 
general data stream header 2-14, 2-31, 2-32 
general data stream variable 2-14, 2-38, 
5.2-5, I-1 
Application Data 5.2-5, 5.2-11, H-17 
Change Number of Sessions 2-38 
See also Change Number of Sessions 60S 
variable 
code points H-16 
Compare States 2-42 
Error Data 5.2-14, 5.2-15, H-18 
Error Log H-19 
Exchange Log Name 2-42 
format H-11 
Map Name 2-39, 5.2-9, 5.2-11, H-17 
Null Data 5.2-5, H-17 
User Control Data 5.2-5, 5.2-11, 5.2-14, 
H~-17 
general data stream variable identifier 2-14 
general data stream variables 
for mapped conversations 2-16, 2-39 
for resynchronization 2-42 
GENERATE_RM_PS_INPUTS procedure 6.1-31 
referenced by 
DFC_RCV_FSMS 6.1-24 
generic finite-state machines N-1 
binding N-1 
no-op finite-state machines N-1 
GET_ATTRIBUTES_PROC procedure 5.1-18 
referenced by 
PS CONV 5.1-10 
GET_END_CHAIN_FROM_HS procedure 5.1-37 
referenced by 
ATTACH_ERROR_PROC 5.0-10 
WAIT_FOR_SEND_ERROR_DONE_PROC 5.1-62 
GET _SEND_INDICATOR procedure 5.2-44 
referenced by 
RCVD_SVC_ERROR_PURGING 5.2-42 
GET_SESSION_PROC procedure 3-45 
referenced by 
BID_RSP_PROC 3-32 
DEQUEUE_WAITING REQUEST 3-42 


PROCESS_PS_YO_RM_RECORD 3-21 
RTR_RQ PROC 3-50 
SESSION _DEACTIVATED_PROC 3-58 

GET_SESSION structure A-~-26 

referenced by 

BID_RSP_PROC 3-32 
BIDDER_PROC 3-34 
DEQUEUE_WAITING_REQUEST 3-42 
FIRST_SPEAKER_PROC 3-43 
GET_SESSION_PROC 3-45 
OBTAIN _SESSION_PROC 5.1-38 
RTR_RQ_PROC 3-50 
SESSION_ACTIVATED_ALLOCATION 3-56 
SESSION_DEACTIVATED_PROC 3-58 
SUCCESSFUL_SESSION_ACTIVATION 3-63 


Le] 


half-duplex flip-flop send/receive mode 2-6 
See also send/receive mode, hal f-duplex 
flip-flop (HDX-FF) 
See also two-way alternate send/receive 
protocol 
half-session (HS) 2-1 
activation and deactivation 6.0-1 
components 6.0-1 
function summary 2-37 
process 2-35, 2-37, 2-42, 2-44, 2-47 
process queues 6.0-2 
processes 6.0-2 
protocol boundaries 2-49, 2-50, 6.0-2 
half-session ID 2-6 
Hardware Product Identifier (X'00') Product 
Identifier Subfield E-24 
HIERARCHICAL_RESET_RSP structure A-18 
referenced by 
BUILD_AND_SEND_HIER_RESET_RSP 4-63 
HIERARCHICAL_RESET structure A-22 
referenced by 
BUILD_AND_SEND_HIER_RESET_RSP 4-63 
PROCESS HIERARCHICAL_RESEY 4-87 
PROCESS_RECORD_FROM_NNM 4-50 
HS 
See half-session (HS) 
HS_ID structure 3-74 
referenced by 
BIDDER_PROC 3-34 
BIS_RACE_LOSER 3-35 
CHECK_FOR_BIS_ REPLY 3-38 
COMPLETE_HS_ATTACH 3-38 
CONNECT_RCB_AND_SCB 3-39 
DEQUEVE_WAITING REQUEST 3-42 
FIRST_SPEAKER_PROC 3-43 
FSM_BIS BIDDER 3-70 
FSM_BIS_ FSP 3-71 
PS_ PROTOCOL_ERROR 5.0-15 
RM_PROTOCOL_ERROR 3-49 
SEND_BIS 3-53 
SEND_BIS_REPLY 3-53 
SEND- BIS_RQ 3-54 
SESSION_ACTIVATED_ALLOCATION 3-56 
SET_RCB_AND_SCB_FIELDS 3-61 
SHOULD_SEND_BIS 3-62 
HS-initiated procedure 
HS process 6.0-3 
referenced by 
BID_PROC 3-39 
BIDDER_PROC 3-34 
BIS _RACE_LOSER 3-35 
CONFIRMED PROC 5.1-14 
CONNECT _RCB_AND SCB 3-39 
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DEALLOCATE_ABEND_PROC 5.1-32 
FIRST_SPEAKER_PROC 3-43 . 
FLUSH PROC 5.1-17 
FREE_ SESSION _ PROC 3-44 
FSM_CONVERSATION 5.1-63 
FSM_ERROR_OR_FAILURE 5.1-65 
PROCESS_RM_OR_HS_TO_PS_RECORDS 5.1~-47 
RECEIVE_RM_OR_HS_TO_PS_RECORD 5.1-51 
REQUEST_TO_SEND_PROC 5.1-23 
RTR_RQ_ PROC 3-50 
SEND_BIS_REPLY 3-53 
SEND_BIS_RQ 3-54 
SEND_DATA_TO_HS_ PROC 5.1-52 
SEND_ERROR_IN_RECEIVE_STATE 5.1-546 
SEND_ERROR_PROC 5.1-26 
SESSION_ACTIVATED_ALLOCATION 3-56 
SUCCESSFUL_SESSION_ACTIVATION 3-63 
WAIT _FOR_CONFIRMED_PROC 5.1-59 
HS_PS_CONNECTED structure A-29 
referenced by 
CONNECT_RCB_AND_SCB 3-39 
DFC_SEND_FROM_RM 6.1-20 
PROCESS_RU_DATA 6.1-34 
SEND_RSP_TO_RM_OR_PS 6.1-39 
HS_RCV_RECORD structure A-11 
referenced by 
BUILD_AND_SEND_CINIT_RSP 4-61 
BUILD_AND_SEND_RSP_OR_LOG 4-66 
CINIT RQ STATE_ERROR 4-71 
DFC_RCV 6.1-23 
FSM_STATUS 4-95 
INITIALIZE LULU_CB_CINIT 4-75 
PROCESS_CINIT_RQ 4-82 
PROCESS_CLEANUP_RQ 4-84 
PROCESS_CTERM_RQ 4-85 
PROCESS _ECHOTEST_RQ 4-87 
PROCESS_INIT_SELF_RSP 4-88 
PROCESS NOTIFY_RQ 4-89 
PROCESS NOTIFY_RSP 4-89 
PROCESS_RECORD_FROM_HS 4-48 
PROCESS REQECHO_RSP 4-90 
PROCESS_TERM_SELF_RSP 4-91 
HS_SEND_RECORD structure A-16 
referenced by 
BUILD_AND_SEND_BINDF_RQ 4-60 
BUILD _AND_SEND_CINIT_RSP 4-61 
BUILD_AND_SEND_INIT_RQ 4-64 
BUILD_AND_SEND_RSP_OR_LOG 4-66 
BUILD_AND_SEND_SESSEND_RQ 4-68 
BUILD_AND_SEND_SESSST_RQ 4-68 
BUILD_AND_SEND_TERM_RQ 4-69 
BUILD_AND_SEND_UNBINDF_RQ 4-70 
DFC_SENO_FROM_LNS 6.1-22 
HS_TO_LNS_RECORD structure A-10 
referenced by 
LNS 4-47 
PROCESS RECORD_FROM_HS 4-48 
HS_TO_PC_RECORD structure A-11 
referenced by 
TC.DEQUEVE_PAC 6.2-18 
TC.EXCHANGE_CRV 6.2-10 
TC.SEND 6.2-13 
HS_TO_PS_RECORD structure A-12 
referenced by 
PROCESS _RM_OR_HS_TO_PS_RECORDS 5.1-47 
RECEIVE RM_OR_HS_TO_PS_RECORD 5.1-51 
WAIT _FOR_CONFIRMED_ PROC 5.1-59 
HS_TO_RM_RECORD structure A-13 
referenced by | 
GENERATE_RM_PS_INFUTS 6.1-31 
PROCESS_HS_TO_RM_RECORD 3-19 
PROCESS _RU_DATA 6.1-34 


i 


identification of session 
‘in BIND 4-24 ; 
‘in BIND image in CINIT | 
PLU network name 4-10 
PLU uninterpreted name 4-10 
in BINDF — 3 
PLU-SLU network addresses 4-11 
in CINIT 
URC 4-10 
in CLEANUP 
PLU-SLU network addresses 4-12 
in CTERM 
PLU-SLU network addresses 4-12 
in INIT-SELF 
BLU uninterpreted name 4-9 | 
URC 4-9 | 
in NOTIFY(Vector Key X'03') 
PLU-SLU network names 4-14 
in SESSEND 
‘ PLU-SLU network addresses 4-13 
in SESSST 
PLU-SLU network addresses 4-11 
in TERM~-SELF 
URC 4-11 
in UNBINDF 
PLU-SLU network addresses 4-13 
identity transformation of uninterpreted 
name 4-5 
ILu 
See initiating LU (ILU) 
ILU/TLU Notification NOTIFY Vector E-12 
immediate request mode 6.1-8 
See also control mode, immediate request 
immediate response mode 6.1-8 
See also control mode, immediate response 
implementation-dependent parameters 4-6 
implementation-determined functions 
See also non-SNA functions 
API 2-4 
closed 2-13 
buffer sizes 2-31, 2-32 
control operator 2-3 
control operator TP 2-38 
error recovery 2-11 
initiating TP locally e2- 
legging 2-40 
mapping 2-39 
names 2-5 
network configuration 2-4 
optional function sets 2-13 
record length and format con- 
straints 2-14, 2-31 
resources 2-30, 2-39, 2~40 
function-shipping | 
system definition 2-46 
implied Forget 
See sync point, commands, implied Forget 
INIT_HS_RSP structure A-11 
referenced by 
BUILD_AND_SEND_ACTLU_RSP_POS 4-58 
FSM_STATUS 4-95 | 
HS 6.0-3 | 
PROCESS_INIT_HS_RSP 4-&8& 
— PROCESS _RECORD_FROM_HS 4-48 
INIT_HS structure A-16 
referenced by | | 
BUILD_AND_SEND_ACTLU_RSP_POS 4-58 
BUILD_AND_SEND_INIT_HS 4-63 
DFC_INITIALIZE 6.1-18 
HS 6.0-3 
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TC.INITIALIZE 6.2-8 
INIT-SELF E-11 
See also INITIATE-SELF 
INIT-SELF Format 1 
See INITIATE-SELF 
initial chaining value 6.2-2, 6.2-3 
INITIALIZE_ATTACHED_RCB procedure 5§.0-16 
referenced by 
PS INITIALIZE 5.0~-6 
INITIALIZE_LULU_CB_ACT_SESS procedure 4-73 
referenced by 
PROCESS_ACTIVATE_SESSION 4-77 
INITIALIZE_LULU_CB_BIND procedure 4-74 
referenced by 
PROCESS_BIND_RQ 4-79 
INITIALIZE_LULU_CB_CINIT procedure 4-75 
referenced by 
PROCESS CINIT_RQ 4-82 
INITIALIZE_SESSION_LIMIT_PROC proce- 
dure 5.4-33 
referenced by 
PS _COPR 5.4-32 
INITIALIZE_SESSION_LIMIT verb 5.4-6, 5.4-20 
processing by PS.COPR 
parallel-session mode name 5.4-29 
single-session mode name 5.4-24 
SNASVCMG mode name 5.4-24 
INITIATE-SELF (INIT-SELF) 4-9, E-11 
initiating LU (ILU) 4-4 
initiator 
See syne point, roles, initiator 
installation-specified parameters 4-6 
intermediate routing 1-4 
internal transaction routine 
INVALID_SENSE_CODE procedure 6.1-32 
referenced by 
RCV_STATE_ERROR 6.1-36 
IPR 
See Isolated Pacing Response (IPR) 
Isolated Pacing Response (IPR) 6.2-5, 6.2-6 


last resource 
See syne point, flows, last resource opti- 
mization 
layer of SNA 2-4, 2-28 
layer protocols 2-4 
length prefix (LL) 2-3, 2-14, 2-16, 2-31, 
§.1-6, I-1 
accumulation and checking 2-31, 2-32 
LL 
See length prefix (LL) 
LLID 
See general data stream header 
LNS 
See LU network services (LNS) 
LNS process 4-47 | 
referenced by 
BUILD_AND_SEND_PC_HS_ CONNECT 4-65 
SEND_ACTIVATE_SESSION 3-52 
SEND_DEACTIVATE_SESSION 3-55 
LNS_TO_HS_RECORD structure A-16 
referenced by 
DFC_SEND_FROM_LNS 6.1-22 
LNS_TO_NNM_RECORD structure A-16 
LNS_TO_RM_RECORD structure A-19 
referenced by 
PROCESS_LNS_TO_RM_RECORD 3-20 
Local Form Session Identifier Control Vec- 
tor E~-22 


local LU characteristics 2-42 
local LU name 

See LU name, local 
local resources 

See resource, loca] 


See sync point, local resources 


LOCAL_SESSION_LIMIT_PROC procedure 5.4-41 


referenced by 


INITIALIZE _SESSION_LIMIT_PROC 5.4-33 


RESET_SESSION_LIMIT_PROC 5.4-34 


LOCAL structure 4-101, 6.0-6 
referenced by 


BIND_RQ_STATE_ERROR 4-52 


BIND _SESSION_LIMIT_EXCEEDED 4-55 
BUILD_AND_SEND_ACTLU_LRSP_NEG 4-57 
BUILD_AND_SEND_BIND_RSP_NEG 4-59 


BUILD_AND_ SEND _CINIT_RSP 4-61 
BUILD_AND SEND DACTLU_RSP 4-62 
BUILD AND _SEND_RSP_OR_LOG 4-66 
BUILD_AND_SEND_UNBIND_RSP 4-70 
CINIT_RQ STATE ERROR 4-71 
DFC_INITIALIZE 6.1-18 

DFC_RCV 6.1-23 

DFC_RCV_FSMS 6.1-24 
DFC_SEND_FROM_LNS 6.1-22 
DFC_SEND_FROM_PS 6.1-19 
DFC_SEND_FROM_RM 6.1-20 
DFC_SEND_FSMS 6.1-25 
FORMAT_ERROR 6.1-26 
FORMAT_ERROR_EXP_RSP 6.1-27 
FORMAT_ERROR_NORM_RSP 6.1-27 
FORMAT_ERROR_RQDFC 6.1-28 
FORMAT_ERROR_RQ FMD 6.1-29 
FORMAT_ERROR SSCP_LU 6.1-30 
FSM_BSM_FMP19 6.1-43 
FSM_CHAIN_RCV_FMP19 6.1-44 
FSM_CHAIN SEND_FMP19 6.1-46 


FSM_IMMEDIATE_RQ_MODE_RCV 6.1-48 


FSM_PAC_RQ_RCV 6.2-21 
FSM_PAC_RQ SEND 6.2-20 
FSM_QRI_CHAIN_RCV_FMP19 6.1-49 
FSM_STATUS 4-95 
GENERATE_RM_PS_INPUTS 6.1-31 
HS 6.0-3 

LNS 4-47 


LU_MODE_SESSION_LIMIT_EXCEEDED 4-76 


OK_TO_REPLY 6.1-33 
PROCESS_ABORT_HS 4-77 
PROCESS ACTLU_RQ 4-78 
PROCESS_BIND_RQ 4-79 
PROCESS BIND_RSP 4-61 
PROCESS CINIT_RQ 4-62 
PROCESS CLEANUP_RQ 4-84 
PROCESS_CP_LU_SESSION 6.0-5 
PROCESS CTERM_RQ 4-85 
PROCESS DACTLU_RQ 4-86 
PROCESS _LU_LU_SESSION 6.0-4 
PROCESS _NOTIFY_RQ 4-89 
PROCESS _RECORD_FROM_HS 4-48 
PROCESS RECORD _FROM_NNM 4-50 
PROCESS RU_DATA 6.1-34 
PROCESS SEND_PARM 6.1-35 
PROCESS_UNBIND_RQ 4-91 
RCV_STATE_ERROR 6.1-36 
SEND_NEG RSP_OR_LOG 6.1-37 
SEND_RSP_TO_RM_OR_PS 6.1-39 
STATE_ERROR_SSCP_LU 6.1-40 
STRAY_RSP 6.1-41 
TC.DEQUEUE_PAC 6.2-18 
TC.EXCHANGE_CRV 6.2-10 
TC.FORMAT_CHECK 6.2-11 
TC.INITIALIZE 6.2-8 

TC.RCV 6.2-15 

TC.RCV_CHECKS 6.2-16 
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X-13 
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TC.RCV_NORM_RQ 6.2-17 
TC.SEND 6.2-13 | 
TC.TRY_TO_ENCIPHER 6.2-14 
TC.TRY_TO_SEND_IPR 6.2-19 
TRY_TO_RCV_SIGNAL 6.1-22 


LOCAL_VERB_PARAMETER_CHECK procedure 5§.4-42 


referenced by 
LOCAL_SESSION_LIMIT_PROC 5.4-41 
local, role of LU and TP 2-5 
lock manager 
See sync point, heuristic decision, and 
lock manager 
log manager 5.3-3, 5.3-19, 5. 3-20, 5.3-25, 
5.3-32, 5.3-33, 5.3-34 
log mismatch 5.3-33, 5.3-34 
See also sync point, log 
log name 
See syne point, log 
logging 2-4 
See also sync point, logging 


logical record 2-14, 2-16, 2-31, 2-32, 5.1-6 


logical unit (LU) 
See LU (logical unit) 
logical unit of work 
See sync point 
logical unit of work (LUW) 5.3-1, 5.3-3, 
5.3-16, 5.3-19, 5.3-24, 5.3-25, 5.3-30, 
5.3-32 
delimiting 5.3-1, 5.3-20, 5.3-32 
distributed 5.3-4 
local 5.3-4 
state of 5.3-4, 5.3-18, 5.3-20, 5.3-22, 
B.3-24, 5.3-25, 5.3-30, 5.3-32 
LOGILAL UNIT STATUS (LUSTAT) 6.1-2, 6.1-4, 
6.1-10, 6.1-12, 6.1-13, 6.1-14, E-1l2 
loser, contention 
See bracket, bidder 
LU (logical unit) 2-1 
association with end users 1-3 
component interaction 2-50 
control block (LUCB) 5.1-1 
creation 2-45 
definition 1-3 
parallel-session 5.4-3 
peripheral 1-5 
Single-session 5.4-3 
structure 2-28 
subarea 1-5 
LU data structures 
LU control block (LUCB) 5.2-4 
transaction program control block 
(TPCB) 5.2-4 
LU definition 5.4-3 
LU_ID structure 5§&.0-20 
referenced by 
PS 5.0-5 
LU-LU password 4-5 
See also session-level security, LU-LU 
password 


LU-LU session 


See session 
LU-LU Session Services Capabilities Control 
Vector E-21 | 
LU-LU Session Services Capabilities NOTIFY 
Vector E-12 
LU-LU sessions 
initiation 
overview 4-3 
RUs 4-7 
status notification RUs 4-7 
See also session status notification 
RUs 
termination 
overview 44-3 


RUs 4-7 
LU-LU verification 4- 5 
See also session-level security, LU-LU 
verification 
LU-mode 2-4 | 
LU-mode entry 5.4-5, 5. 4-12 
locking for CNOS 
See change number of sessions (CNOS), 
locking (LU,mode) entry 
processing by PS.COPR (CNOS) 5.4-8, 
5.4-27 
LU_MODE_SESSION_LIMIT_EXCEEDED proce- 
dure 4-76 
referenced by 
ACTIVATE_SESSION_ERROR 4-51 
BIND_SESSION_LIMIT_EXCEEDED 4-55 
CINIT_RQ_STATE_ERROR 4-71 
LU name 2-6, 2-34 
fully qualified 2-6, 2-42 
local 2-6, 2-42 
—network-quali fied 
See LU name, fully qualified 
uninterpreted 2-6, 2-42 
LU_LNAME structure 3-74 
referenced by 
ACTIVATE_NEEDED_SESSIONS 3-22 
BIS_RACE_LOSER 3-35 
CREATE_SCB 3-40 
DEACTIVATE_PENDING SESSIONS 3-41 
DEQUEUE_WAITING REQUEST 3-42 
SEND_ACTIVATE_SESSION 3-52 
SESSION_ACTIVATION_POLARITY 3-57 
SESSION_DEACTIVATION_POLARITY 3-60 
SHOULD_SEND_BIS 3-62 
SUCCESSFUL_SESSION_ACTIVATION 3-63 
UNSUCCESSFUL_SESSION_ACTIVATION 3-66 
LU network services (LLNS) 4-1 
formal description 4-46 
function summary 2~-36 
general description 4-1 
process 2-45 
protocol boundaries 2-49, 2-50, 4-32 
LU services manager 
See LU network services (LNS) 
See resources manager (RM) 
LU services record 


See Change Number of Sessions GOS variable 


LUCB_LIST_PTR structure 5.0-20 
referenced by 

PS 5.0-5 

LUCB structure 2-42, A-] 

referenced by 

BUILD_AND_SEND BIND RQ 4-59 
BUILD_ANO_SEND_ BIND _RSP_POS 4-60 
CHANGE_SESSION_LIMIT_PROC 5.4-35 
CHECK_CNOS_COMMAND 5.4-63 
CHECK_CNOS REPLY 5.4-56 
DEFINE PROC 5.4-38 
DELETE_PROC 5.4-40 
DISPLAY_PROC 5.4-39 
GET_ATTRIBUTES PROC 5.1-18 
INITIALIZE_SESSION LIMIT PROC 5.4-33 
LNS 4-47 
LOCAL_SESSION_LIMIT_PROC 5.4-41 
LOCAL_VERB_PARAMETER_CHECK 5.4-42 
PROCESS BIND_RQ 4-79 
PROCESS BIND_RSP 4-81 
PROCESS SESSION_LIMIT_PROC 5.4-58 
PROCESS _UNBINOD_RQ 4-91 
PS 5.0-5 
PS_ATTACH_ CHECK 5.0-8 
RESET_SESSION_LIMIT_PROC 5.4-34 
SECURITY_PROC 3-52 
SESSION_LIMIT_DATA_LOCK_MANAGER 5.4-67 
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SNASVCMG_VERB_PARAMETER_CHECK 5.4-43 
SOURCE_CONVERSATION 5.4-50 
SOURCE_CONVERSATION_CONTROL 5.4-49 
VERB_PARAMETER_CHECK 5.4-48 


LULU_CB structure A-5 


referenced by 
BIND_RSP_STATE_ERROR 4-53 
BUILD _AND_SEND_ACT_SESS_RSP_NEG 4-56 
BUILD_AND_SEND_ACT_SESS_RSP_POS 4-57 
BUILD_AND_SEND_ACTLU_LRSP_POS 4-58 
BUILD_AND_SEND_BIND_RQ 4-59 
BUILD_AND_SENO_BIND_RSP_POS 4-60 
BUILD_AND_SEND_BINDF_RQ 4-60 
BUILD_AND_SEND_INIT_HS 4-63 
BUILD_AND_SEND_INIT_RQ 4-64 
BUILD_AND_SEND_PC_CONNECT 4-64 
BUILD_AND_SEND_SESS_ ACTIVATED 4-67 
BUILD_AND_SEND_SESSEND_RQ 4-68 
BUILD_AND_SEND_SESSST_RQ 4-68 
BUILD_AND_SEND_TERM_RQ 4-69 
BUILD_AND_SEND_UNBIND_RQ 4-69 
BUILD_AND_SEND_UNBINDF_RQ 4-70 
CINIT_RQ_STATE_ERROR 4-71 
CLEANUP_LU_LU_SESSION 4-72 
FSM_STATUS 4-95 
INITIALIZE _LULU_CB_ACT_SESS 4-73 
INITIALIZE_LULU_CB_BIND 4-74 
INITIALIZE _LULU_CB_CINIT 4-75 
PROCESS_ABORT_HS 4-77 
PROCESS _ACTIVATE_SESSION 4-77 
PROCESS BIND_RQ 4-79 
PROCESS BINO_RSP 4-81 
PROCESS CINIT_RQ 4-82 
PROCESS_CLEANUP_RQ 4-84 
PROCESS CTERM_RQ 4-85 
PROCESS DEACTIVATE_SESSION 4-87 
PROCESS_INIT_HS_RSP 4-88 
PROCESS_INIT_SELF_RSP 4-88 
PROCESS _NOTIFY RQ 4-89 
PROCESS PC_CONNECT_RSP 4-90 
PROCESS SESSION_ROUTE_INOP 4-90 
PROCESS _UNBIND_RQ 4-91 
PROCESS _UNBIND_RSP 4-92 


LUSTAT E-1l2 


See also LOGICAL UNIT STATUS 


LUSTAT (LOGICAL UNIT STATUS) 6.1-14 
LUW 


See logical unit of work (LUW) 


[| 


maintenance services RUs 2-18, 4-29 


ECHOTEST 4-31 
REQECHO 4-31 


mapping 2-7, 2-13, 2-16, 2-31, 2-39, 5.2=1,5 
5.2-8 
errors 5.2-14 
map names 5.2-8, 5.2-9, 5.2-12 
mapper 5.2-8, 5.2-11, 5.2-12, 5.2-14 
parameters 5.2-10 
save area 5.2-4, 5.2-8) 5.2-9 
receive mapping 5.2-11 
receive-buffer list 5.2-4 
send mapping 5.2-9, 5.2-10 
maximum send size 5.2-5, 5.2-4 
MC_ALLOCATE_PROC procedure 5.2-20 
referenced by 
PS_MC §.2-19 
MC_CONFIRM_PROC procedure 5.2-21 
referenced by 
PS MC 5.2-19 
MC_CONFIRMED_PROC procedure 5.2-22 
referenced by 
PS MC 5.2-19 
MC_DEALLOCATE_PROC procedure 5.2-23 
referenced by 
PS MC 5.2-19 
MC_FLUSH_PROC procedure 5.2-23 
referenced by 
PS MC 5.2-19 
MC_GET_ATTRIBUTES PROC procedure 5.2-24 
referenced by 
PS MC 5.2-19 
MC_POST_ON_RECEIPT_PROC procedure 5§.2-25 
referenced by 
PS MC 5.2-19 


MC_PREPARE_TO_RECEIVE_ PROC procedure 5.2-26 


referenced by 
PS MC 5.2-19 
MC_RECEIVE_AND WAIT_PROC procedure 5.2~-27 
referenced by 
PS MC 5.2-19 
MC_REQUEST_TO_SEND_PROC procedure 5.2-37 
referenced by 
PS MC 5.2-19 
MC_SEND_DATA_PROC procedure 5.2-38 
referenced by 
PS MC 5.2-19 
MC_SEND_ERROR_PROC procedure 5.2-40 
referenced by 
PS MC 5.2-19 
MC_TEST_PROC procedure 5.2-28 
referenced by 
PS MC 5.2-19 
TEST_FOR_RESOURCE_POSTED 5§.0-17 
message-unit transformation 2-31 
basic conversation 2-16, 2-32 
mapped conversation 2-16, 2-31 
See also mapping 
message units 2-13 
basic conversation 2-14 


manager component CNOS 
map 2-39 See Change Number of Sessions 605 vari- 
map name 2~39 able 
globally Known 2-39 conversation sequences 2-15 
receiver locally known 2-39 data record 
sender locally know 2-39 See data record 
mapped conversation 2-3, 2-13, 5.2-3, 5.2-5 header 2-14 
See also conversation length limitations 2-14, 2-15 
data stream format 5.2-5 mapped conversation 2-14 
errors 5.2-14, 5.2-16, 5.2-17 session 2-15 
function summary 5.2-1 session sequences 2-16 
initiation 5.2-7 mode 
protocol boundary 5.2-1 control bleck 3-3, 5.1-2 
termination 5.2-7 Mode/ Class-of-Service/ 
mapped-conversation message 2-15 Virtuel-Route-Identifier-List Control Vec- 
mapped-conversation record 2-14, 2-16, 2-31 tor E-21 
mapper 2-39 mode name 2-6, 2-34, 2-42, 4-5 
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in CINIT 4-9 
in INIT-SELF 4-9 
MODE_NAME structure 3-74 


deriving BIND image from 4-5 [*] 


referenced by name 2-4 
ACTIVATE_NEEDED_SESSIONS 3-22 fully qualified LU 
ACTIVATE _SESSION_RSP_PROC 3-23 See LU name, fully qualified 
BIS_RACE_LOSER 3-35 local alias 2-5 
CREATE_SCB 3-40 LU 
DEACTIVATE_PENDING_SESSIONS 3-41 See LU name 
DEQUEUVE_WAITING REQUEST 3-42 mode 
SEND_ACTIVATE_SESSION 3-52 See mode name 
SESSION_ACTIVATION_POLARITY 3-57 mame translation 2-5, 2-6, 2-16 
SESSION_DEACTIVATION_POLARITY 3-60 naming conventions 
SHOULD_SEND_BIS 3-62 using periods 1-5 
SUCCESSFUL_SESSION_ACTIVATION 3-63 using underscores 1-5 
UNSUCCESSFUL_SESSION_ACTIVATION 3-66 NAU (network addressable unit) 2-16 
Mode Name Structured Data Subfield £E-16 definition 1-3 
MODE structure 2-42, A-3 negative response 
referenced by | sense data included with 6-1 
ACTIVATE _NEEDED_SESSIONS 3-22 negotiable BIND 4-20, 4-25 
ACTIVATE_SESSION_ERROR 4-51 NEGOTIATE_REPLY procedure 5.4-64 
ACTIVATE_SESSION_RSP_PROC 3-23 nested nodes 1-4 
ALLOCATE_PROC 5.1-11 network 
BID_PROC 3-30 path control 1-3, 1-5 
BIND_RQ_STATE_ERROR 4-52 SNA 1-3 
BIND_SESSION_LIMIT_EXCEEDED 4-55 network address 2-6, 2-16, 2-36 
BIS_RACE_LOSER 3-35 network address of LU 
BUILD_AND_SEND_BIND_RSP_POS 4-60 in BINDF 4-11 
CHANGE_ACTION 5.4-44 in CLEANUP 4-12 
CHANGE_SESSIONS_PROC 3-37 in CTERM 4-12 
CHECK_CNOS_COMMAND 5.4-63 in SESSEND 4-13 
CHECK_CNOS_ REPLY 5.4-56 in SESSST 4-11 
CHECK _FOR_CIS_REPLY 3-38 in UNBINDF 4-13 
CINIT_RQ_STATE_ERROR 4-71 Network Address Pair Session Key £E-23 
CLOSE_ONE_REPLY 5.4-65 network addressable unit 
DEACTIVATE_PENDING_SESSIONS 3-4] See NAU (network addressable wit) 
DEFINE PROC 5.4-38 network ID 2-6 
DELETE_PROC 5.4-40 network LU name 2-6 
DISPLAY_PROC 5.4-39 network name 4-5 
INITIALIZE _LULU_CB_BIND 4-74 network name of LU 
INITIALIZE LULU CB _CINIT 4-75 in BIND image 4-10 
LOCAL_VERB_PARAMETER_CHECK 5.4-42 in NOTIFY( Vector Key X'03') 4-14 
LU_MODE_SESSION_LIMIT_EXCEEDED 4-76 Network Name Pair Session Key E-23 
 NEGOTIATE_REPLY 5.4-64 Network-Qualified Address Pair Control Vec- 
PROCESS _SESSION_LIMIT_PROC 5.4-58 tor E-21 
SEND_ACTIVATE_SESSION 3-52 Network-Qualified Address Pair Session 
SEND_BIS_REPLY 3-53 Key E-23 
SEND_BIS_RQ 3-54 network-qualified LU name 
SEND_DEACTIVATE_SESSION 3-55 See LU name, fully qualified 
SESSION_ACTIVATED_PROC 3-57 | NNM_TO_LNS_RECORD structure A-21 
SESSION_ACTIVATION_POLARITY 3-57 referenced by 
SESSION_DEACTIVATED_PROC 3-58 LNS 4-47 
SESSION_DEACTIVATION_POLARITY 3-60 PROCESS_RECORD_FROM_NNM 4-50 
SESSION_LIMIT_DATA_LOCK_MANAGER 5.4-67 no-op finite-state machines N-1 
SHOULD_SEND_BIS 3-62 node 
SNASVCMG_VERB_PARAMETER_CHECK 5.4-43 definition 1-3 
SOURCE_CONVERSATION_CONTROL 5.4-49 SNA 1-3, 1-4 
SOURCE_SESSION_LIMIT_PROC 5.4-46 SNA product 1-3, 1-4 
UNSUCCESSFUL_SESSION_ACTIVATION 3-66 synonymous with "SNA node" 1-3 
VERB_PARAMETER_CHECK 5.4-48 type 
wmode, control 1 1-3 
See control mode 2.0 1-3 
wode, LU 2-3, 2-4, 2-6) 2-42 2.1 1-3 
See also transport characteristics G 1-3 
wodifier value, sense code 6-1 5 1-3 
See also sense data user-application 1-3, 1-4 
multiple-session LU 2-7 node type 2-16 
See also session, parallel nodes 


nesting of 1-3; 1-4 
non-SNA functions | 
See also implementation-deterained furnc- 
tions 
API 2-4 
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error recovery 2-11 
mapping 2-39 
names 2-5 
resources 2-11, 2-30, 2-40 
local 2-4 
normal flow 6.2-! 
session-level pacing 6.2-5 
TC 6.2-4 
normal-flow send/receive mode 
See send/receive mode 
notational conventions, general 1-5 
notification 
of changes in LU's session services capa- 
bilities 4-14 
of LU's availability 
using NOTIFY(Vector Key X'0C') 4-14 
of session initiation failure. 
using NOTIFY(Vector Key X'03') 4-14 
of session termination failure 
using NOTIFY(Vector Key X'03') 4-14 
NOTIFY 4-14, E-12 
NOTIFY Vector 
ILU/TLU Notification E-12 
LU-LU Session Services Capabilities E-12 


Gi 


OAF'-DAF' assignor indicator (QDAI) 4-19 
OBTAIN_SESSION_PROC procedure 5.1-38 
referenced by 
RCB_ALLOCATED_PROC 5.1-48 
SEND_DATA_TO_HS_PROC 5.1-52 
ODAI 
See OAF'-DAF" assignor indicator (ODAI) 
OK_TO_LREPLY procedure 6.1-33 
referenced by 
FSM_CHAIN_RCV_FMPI9 6.1-44 
FSM_CHAIN_SEND_FMPI9 6.1-46 
GENERATE_RM_PS_INPUTS 6.1-31 
OLU 
See origin LU (OLU) 
one-way conversation 2-6 
operator 
See control operator 
operator messages, sync point 
See syne point, operator messages 
optimized flows 
See syne point, flows 
optional function sets 2-12, 2-13, 2-38, 
2-42 
CNOS 5.4-21 
receive options 2-13 
send options 2-13 
origin LU (OLU) 4-4 
origin transaction program 2-7 


td 


pacing 6.2-6 
See also session-level pacing 
initialization 6.2-2 
pacing queue 6.2-6 
Queued Response indicator (QRI) 6.2-6 
session-level 6.2-1, 6.2-4, 6.2-5 
deadlock 6.2-6 
FSM_PAC_RQ RCV 6.2-21 
FSM_PAC_RQ_SEND 6.2-20 
IPR 6.2-6 


pacing count 6.2-6 
parameter set up 6.2-2, 6.2-6 
PI 6.2-5, 6.2-6 
stages 6.2-5 
window size 6.2-5 
Pacing Request indicator (PI) 6.2-5 
Pacing Response indicator (PI) 6.2-5, 6.2-6 
Padded Data indicator (PDI) 6.2-5 
padding H-2 
parallel session 
See session, parallel 
parallel session LU 2-7, 2-38 
See also session, parallel 
partner LU 2-4, 2-42 
See also remote, role of LU and TP 
control block 5.1-2 
PARTNER_LU structure 2-42, A-2 
referenced by 
ACTIVATE_SESSION_ERROR 4-51 
BIND_RQ_STATE_ERROR 4-52 
BIND_SESSION_LIMIT_EXCEEDED 4-55 
BUILD_AND_SEND_BIND_RSP_POS 4-60 
CHANGE_ACTION 5.4-44 
CHECK_CNOS_COMMAND 5.4-63 
CHECK_CNOS_REPLY 5.4-56 
CINIT_RQ_STATE_ERROR 4-71 
CLOSE_ONE_REPLY 5.4~-65 
DEFINE PROC 5.4-38 
DELETE_PROC 5.4-40 
DISPLAY PROC 5.4-39 
GET_ATTRIBUTES_PROC 5.1-18 
INITIALIZE_LULU_CB_ACT_SESS 4-73 
INITIALIZE_LULU_CB_BIND 4-74 
INITIALIZE_LULU_CB_CINIT 4-75 
LOCAL_VERB_PARAMETER_CHECK 5.4-42 
NEGOTIATE_REPLY 5.4-64 
PROCESS SESSION_LIMIT_PROC 5.4-58 
SESSION_LIMIT_DATA_LOCK_MANAGER 5.4-67 
SNASVCMG_VERB_PARAMETER_CHECK 5.4-43 
SOURCE_CONVERSATION 5.4-50 
SOURCE_CONVERSATION_CONTROL 5.4-49 
SOURCE_SESSION_LIMIT_PROC 5.4-46 
VERB_PARAMETER_ CHECK 5.4-48 
password 
See conversation-level security 
See session-level security 
path control network 1-3, 1-5, 2-1, 2-28 
protocol boundary with LU 2-28, 2-49 
PC 
See path control network 
PC_CHARACTERISTICS structure A-35 
PC_CONNECT_RSP structure A-22 
referenced by 
FSM_STATUS 4-95 
PROCESS_PC_CONNECT_RSP 4-90 
PROCESS_RECORD_FROM_NNM 4-50 
PC_CONNECT structure A-18 
referenced by 
BUILD_AND_SEND_PC_CONNECT 4-64 
PC_HS_CONNECT structure A-18 
referenced by 
BUILD_AND_SEND_PC_HS_CONNECT 4-65 
PC_HS_DISCONNECT structure A-19 
referenced by 
BUILD_AND_SEND_PC_HS_DISCONNECT 4-65 
PC_TO_HS_RECORD structure A-23 
referenced by 
TC. EXCHANGE CRV 6.2-10 
TC.ROV 6.2-15 
PDI 
See Padded Data indicator (PDI) 
peer protocols 2-4 
PERFORM_RECEIVE_ PROCESSING procedure 5.1-39 
referenced by 


Index X-17 


X~18 


PROCESS_FMH7_PROC 5.1-46 
RECEIVE _AND_WATT_PROC 5.1-20 
RECEIVE IMMEDIATE _PROC 5.1-22 
performance-related options 2-13 
periods, separating name qualifiers denoting 
decomposition 1-5 
peripheral LU 1-5 
peripheral node 1-4 
See also node 
peripheral node control point CPNCP) 
See PNCP (peripheral node control point) 
peripheral node to peripheral node communi - 
cation 2-1 
See also PNCP-mediated sessions 
peripheral node to subarea node communi- 
cation 2-1 
See also SSCP-mediated sessions 
peripheral PU 1-5 
phases, sync point 
See sync points commands 
physical unit (PU) 
See PU (physical unit) 
PY 
See Pacing Request or Pacing Response 
indicator (PI) 
PIP 
See program initialization parameters 
(PIP) 
PIP_FIELD structure 5.0-19 
referenced by 
PS_ATTACH_ CHECK 5.0-8 
PS_INITIALIZE 5.0-6 
RECEIVE PIP_FIELD_FROM_HS 5.0-7 
PIP_LIST structure 5.0-20 
referenced by 
PS_INITIALIZE 5.0-6 
PIP Variable H-7 
PIU structure A-35 
PLU 
See primary LU (PLU) 
PLU name 
in BIND 4-23 
PNCP (peripheral node control point) 1-5, 
4-2 
PNCP-mediated sessions 4-2 
POST_AND_WAIT_PROC procedure 5.1-40 
referenced by 
CONFIRM_PROC 5.1-12 
DEALLOCATE_CONFIRM_PROC 5.1-33 
PREPARE_TO_RECEIVE_CONFIRM_PROC 5.1-41 
PROCESS_FMH7_PROC 5.1-46 
RECEIVE _ANO_WAIT_PROC 5.1-20 
RECEIVE_IMMEDIATE_PROC 5.1-22 
SEND_DATA_PROC 5.1-24 
SEND_ERROR_IN_SEND_STATE 5.1-55 
TEST_PROC 5.1-27 
WAIT_FOR_CONFIRMED_PROC 5.1-59 
POST_ON_RECEIPT_PROC procedure 5.1-18 
referenced by 
PS CONV 5.1-10 
Prepare 
See sync point, commands, Prepare 
PREPARE TO_RECEIVE_CONFIRM_PROC proce-~ 
dure 5.1-41 
referenced by 
PREPARE TO_RECEIVE_PROC 5.1-19 
PREPARE_TO_RECEIVE_FLUSH_PROC proce- 
dure 5.1-43 
referenced by 
PREPARE _TO_RECEIVE PROC 5.1-19 
PREPARE_TO_RECEIVE_PROC procedure 5.1-19 
referenced by 
PS_ CONV 5.1-10 | 
presentation services (PS) 5.0-1, 5.2-1 


creation 3-17 
data structures 5.2-4 
function summary 2-37 
process 2-34, 2-35, 5.0-3 
protocol boundaries 2-49, 5,0-2 
structure 2-30, 5.0-2, S.1-1 
termination 3-17 
presentation services (PS) headers 2-40, 
5.1-6, 5.3-6, 5.3-7, 5.3-8, 5.3-35 
definition H-10 
format H-10 
presentation services (PS) initialize 2-30; 
§.0-3 
See also presentation services (PS) 
protocol boundaries 5.0-3 
presentation services (PS) verb router 2-30, 
5.0-4 
See also presentation services (PS) 
See also recursion in PS 
presentation services for conversations 
(PS.CONV) 2-30 
See also presentation services (PS) 
function summary 5.1-1 
protocol boundaries 2-49, 5.1-1 
structure 5.1-1 
presentation services for mapped conversa- 
tions (PS.MC)} 2-30, 2-39 
See also mapped conversation 
See also mapping 
See also presentation services (PS) 
protocol boundaries 2-49 
presentation services for sync point services 
(PS.SPS) 2-30, 2-40 
See also presentation services (PS) 
See also sync point 
protocol boundaries 2-40 
presentation services for the control opera- 
tor (PS.COPR) 2-30, 5.4-1, 5.4-21 
See also change number of sessions (CNOS) 
See also presentation services (PS) 
local-verb services 5§.4-24 
protocol boundaries 2-49 
session-limit-data lock 5.4-12, 5.4-31 
session-lLimit-data-lock manager 5.4-12; 
5.4-14, 5.4-30 
shared data 5.4-12 
See also LU-mode entry 
source-LU session-limit services 5.4-12, 
5.4-14, 5.4-25 
See also change number of sessions 
(CNOS), component relationship, 
source-LU services 
structure 5.4-1, 5.4-23 
target-LU session-limit services 5.4-12, 
5.4-15, 5.4-28 
See also change number of sessions 
(CNOS), component relationship, 
target-LU services 
verb router 5.4-24 
presentation services verb router 5.2-3 
presentation space 2-7 
primary LU (PLU) 2-8, 2-35, 2-36, 4-4 
See also session, activation polarity 
primary LU name 
in BIND 4-23 
process 2-42 
PROCESS ABORT_HS procedure 4- 77 
referenced | by 
PROCESS _ RECORD. FROM_HS 4-48 
PROCESS _ ACTIVATE. SESSION procedure 4-77 
referenced by 
PROCESS _RECORD_FROM_RM 4-48 
PROCESS ACTLU_RQ procedure 4-78 
referenced by 
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PROCESS _RECORD_FROM_NNM 4-50 referenced by 


PROCESS_BIND_RQ procedure 4-79 PROCESS_RECORD_FROM_HS 4-48 
referenced by PROCESS_PC_CONNECT_RSP procedure 4-90 
PROCESS_RECORD_FROM_NNM 4-50 referenced by 
PROCESS _BIND_RSP procedure 4-81 PROCESS _RECORD_FROM_NNM 4-50 
referenced by PROCESS_PS_TO_RM_RECORD procedure 3-21 
PROCESS _RECORD_FROM_NNM 4-50 referenced by 
PROCESS _CINIT_RQ procedure 4-82 RM 3-18 
referenced by PROCESS_RECORD_FROM_HS procedure 4-48 
PROCESS RECORD_FROM_HS 4-48 referenced by 
PROCESS CLEANUP_RQ procedure 4-84 LNS 4-47 
referenced by PROCESS_RECORD_FROM_NNM procedure 4-50 
PROCESS _RECORD_FROM_HS 4-48 referenced by 
process connection 2-35, 2-37 LNS 4-47 
PROCESS_CP_LU_SESSION procedure 6.0-5 PROCESS_RECORD_FROM_RM procedure 4-48 
referenced by referenced by 
HS 6.0-3 LNS 4-47 
PROCESS CTERM_RQ procedure 4-85 PROCESS _REQECHO_RSP procedure 4-90 
referenced by referenced by 
PROCESS_RECORD_FROM_HS 4-48 PROCESS_RECORD_FROM_HS 4-48 
PROCESS_DACTLU_RQ procedure 4-86 PROCESS_RM_OR_HS_TO_PS_RECORDS proce- 
referenced by dure 5.1-47 
PROCESS_RECORD_FROM_NNM 4-50 referenced by 
PROCESS DATA_COMPLETE procedure 5.2-33 CONFIRM_PROC 5.1-12 
referenced by CONFIRMED_PROC 5.1-14 
RECEIVE_INFO_PROC 5.2-30 DEALLOCATE_ABEND PROC 5.1-32 
PROCESS_DATA_INCOMPLETE procedure 5.2-36 DEALLOCATE_CONFIRM_PROC 5.1-33 
referenced by DEALLOCATE_FLUSH_PROC 5.1-35 
RECEIVE INFO_PROC 5.2~30 FLUSH_PROC 5.1-17 
PROCESS_DATA_PROC procedure 5.1-44 POST_AND_WAIT_PROC 5.1-40 
referenced by POST_ON_RECEIPT_PROC 5.1-18 
PERFORM_RECEIVE PROCESSING 5.1-39 PREPARE _TO_RECEIVE CONFIRM_PROC 5.1-41 
PROCESS_DEACTIVATE_SESSION procedure 4-87 PREPARE_TO_RECEIVE FLUSH _PROC 5.1-43 
referenced by RECELVE_AND_WAIT_PROC 5.1-20 
PROCESS RECORD_FROM_RM 4-48 RECEIVE _IMMEDIATE_FPROC 5.1-22 
PROCESS _ECHOTEST_RQ procedure 4-87 REQUEST_TO_SEND_PROC 5§.1-23 
referenced by SEND_DATA_PROC 5.1-24 
PROCESS_RECORD_FROM_HS 4-48 SEND_ERROR_PROC 5.1-26 
PROCESS_ERROR_DATA procedure 5.2-43 SET_FMH7_RC 5.1-57 
referenced by TEST_PROC 5.1-27 
RCVD_SVC_ERROR_PURGING 5.2-42 PROCESS_RU_DATA procedure 6.1-34 
PROCESS ERROR OR_FAILURE_RC procedure 5.2-31 referenced by 
referenced by GENERATE_RM_PS_INPUTS 6.1-31 
MC_TEST_PROC 5.2-28 PROCESS _SEND_PARM procedure 6.1-35 
RECEIVE_INFO_PROC 5.2-30 referenced by 
PROCESS_FMH7_PROC procedure 5.1-46 DFC_SEND_FROM_FS 6.1-19 
referenced by DFC_SEND_FROM_RM 6.1-20 
DEQUEUE_FMH7_PROC 5.1-36 . PROCESS SESSION _LIMIT_PROC procedure 5.4-58 
PERFORM_RECEIVE_ PROCESSING 5.1-39 referenced by 
PROCESS HIERARCHICAL_RESET procedure 4-87 PS_COPR 5.4-32 
referenced by PROCESS_SESSION_LIMIT verb 5§.4-6 
PROCESS_RECORD_FROM_NNM 4-50 processing by PS.COPR 5.4-22, 5.4-28 
PROCESS_HS_TO_RM_RECORD procedure 3-19 PROCESS_SESSION ROUTE_INOP procedure 4-90 
referenced by referenced by 
RM 3-18 PROCESS _RECORD_FROM_NNM 4-50 
PROCESS _INIT_HS RSP procedure 4-88 PROCESS TERM_SELF_RSP procedure 4-91 
referenced by referenced by 
PROCESS_RECORD_FROM_HS 4-48 PROCESS_RECORD_FROM_HS 4-48 
PROCESS_INIT_SELF_RSP procedure 4-88 PROCESS _UNBINO_RQ procedure 4-91 
referenced by referenced by 
PROCESS_RECORD_FROM_HS 4-48 PROCESS_RECORD_FROM_NNM 4-50 
PROCESS_LNS_TO_RM_RECORD procedure 3-20 PROCESS _UNBIND_RSP procedure 4-92 
referenced by referenced by 
RM 3-18 PROCESS_RECORD_FROM_NNM 4-50 
PROCESS _LU_LU_ SESSION procedure 6.0-4 Product Identifier (X'11') Common Subvec- 
referenced by tor E-24 
HS 6.0-3 Product Identifier Subfield 
PROCESS _MAPPER_RETURN_CODE procedure 5.2-35 Emulated Product Identifier (X'01') E-25 
referenced by Hardware Product Identifier (X'00') E-24 
PROCESS _DATA_COMPLETE 5.2-33 Software Product Common Level 
PROCESS _NOTIFY_RQ procedure 4-89 (X'04") E-25 : 
referenced by Software Product Common Name (X'06') E-26 
PROCESS RECORD_FROM_HS 4-48 Software Product Customization Date and 
PROCESS_NOTIFY_RSP procedure 4-89 Time (X'09') E-26 


Index X-19 


X-20 | 


Software Product Customization Identifier 


(X'O7') E-26 

Software Product Program Number 
(X'08') E-26 

Software Product Serviceable Component 
Identifier (X'02') E-25 


Product Set ID (X'10') Common Subvector E-24 


profile, security 
See conversation-level security 
profiles 2-9 


corresponding to type of session F-4, F-6 


FM (function management) F-1 
FM profile 0 2-9, F-1 
FM profile 19 2-9, F-3 
FM profile 6 2-9, F-2 
TS (transmission services) F-5 
TS profile 1 2-9, F-5 
TS profile 7 2-9, F-5 
program initialization parameters 
(PIP) 2-13, 5.0-4 
program-to-program communication 2-1 
protection 
See sync point 
protection manager 
See sync point, protection manager 
protocol boumdary 2-4, 2-49 
See also application program interface 
(APT) 
See also under individual component 
between layers 2-4 
between peer components 2-4 
general definition 1-1 
internal 2-49 
partitioned 2-4 
PROTOCOL_ERROR_PROC procedure 5.2-47 
referenced by 
GET_SEND_INDICATOR 5.2-44 
MC_TEST_PROC 5.2-28 
PROCESS _DATA_COMPLETE 5.2-33 
PROCESS _DATA_INCOMPLETE 5.2-36 
PROCESS ERROR_DATA 5.2-43 
PROCESS_ERROR_OR_FAILURE_RC 5.2-31 
PROCESS MAPPER_RETURN_CODE 5.2-35 
RCVD_SVC_ERROR_PURGING 5.2-42 


RCVD_SVC_ERROR_TRUNC_NO_TRUNC 5.2-41 


RECEIVE _INFO_PROC 5.2~-30 
SEND_SVC_ERROR_PURGING 5.2-45 
protocol machine, definition of 1-1 
PS 
See presentation services (PS) 
PS_ATTACH_CHECK procedure 5.0-8 
referenced by 
PS_INITIALIZE 5.0-6 
PS. CONV 


See presentation services for conversa- 


tions (PS.CONV) 
PS_CONV procedure 5.1-10 
referenced by 
PS VERB_ROUTER 5.0-11 
PS .COPR 


See presentation services for the control 


operator (PS.COPR) 
PS_COPR procedure 5.4-32 
referenced by 
PS _VERB_ROUTER 5.0-11 
PS _CREATION_PROC procedure 3-47 
referenced by 
ATTACH _ PROC 3-27 
PS header 
See presentation services (PS) headers 
PS header 10: Syne Point Control H-10 
PS_INITIALIZE procedure 5.0-6 
“referenced by 
PS 5.0-5 


PS .MC 


See presentation services for mapped con- 
versations (PS.MC) 


PS_MC procedure 5.2-19 


referenced by 
PS VERB ROUTER 5.0-11 


PS process 5.0-5 


referenced by | 
ALLOCATE PROC 5.1-11 
ALLOCATE_RCB_PROC 3-24 
ATTACH_PROC 3-27 
BID_RSP_PROC 3-32 
CONFIRMED_PROC 5.1-14 
CONNECT_RCB_AND_SCB 3-39 
DEALLOCATE_ABEND_PROC 5.1-32 
FIRST_SPEAKER_PROC 3-43 
FLUSH_PROC 5.1-17 
GET_SESSION_ PROC 3-45 
INITIALIZE_ATTACHED_RCB 5.0-16 
PROCESS _PS_TO_RM_RECORD 3-21 
PROCESS _RM_OR_HS_TO_PS_RECORDS 5.1-47 
PS_CREATION_ PROC 3-47 
RECEIVE _RM_OR_HS_TO_PS_RECORD 5.1-51 
RM_ACTIVATE_SESSION_PROC 3-48 
SEND_DATA_TO_HS_PROC 5.1-52 
SEND_DEACTIVATE_SESSION 3-55 
SEND_ERROR_IN_RECEIVE_STATE 5.1-54 
SEND_ERROR_PROC 5.1-26 
SEND_ERROR_TO_HS_PROC 5.32-56 
SESSION_ACTIVATED_ALLOCATION 3-56 
SESSION_DEACTIVATED_PROC 3-58 
SUCCESSFUL_SESSION_ACTIVATION 3-63 
UNSUCCESSFUL_SESSION_ACTIVATION 3-66 
WATT FOR _CONFIRMED_PROC 5.1-59 
WAIT _FOR_RM_REPLY 5.1-60 


PS PROCESS DATA structure 5.0-2, 5.0-19, 
5.1-3 


referenced by 
ACTIVATE_SESSION_PROC 5.4-36 
ATTACH_ERROR_PROC 5.0-10 
DEACTIVATE_SESSION_PROC 5.4-37 
DEALLOCATION_CLEANUP_PROC 5.0-13 
INITIALIZE_ATTACHED_RCB 5.0-16 
PS 5.0-5 
PS_ATTACH_CHECK 5.0-8 
PS_INITIALIZE 5.0-6 
PS _PROTOCOL_ERROR 5.0-15 
PS VERB_ ROUTER 5.0-1]1 | : 
RECEIVE_PIP_FIELD_FROM_HS 5.0-7 
TEST_FOR_RESOURCE_POSTED 5.0-17 
WAIT_PROC 5.0-13 


PS profile 


in BIND 4-22 


—PS_PROTOCOL_ERROR procedure 5, 0-15 


referenced by 
ATTACH_ERROR_PROC 5.0-10 
DEQUEUE_ FMH7_ PROC 5.1-36 
PERFORM. RECEIVE_ PROCESSING 5.1-39 
PROCESS _DATA_ PROC §.1-44 
PROCESS FMH7_PROC 5.1-46 
PROCESS_RM_OR_HS_TO_PS_RECORDS 5.1-47 
RECEIVE_PIP_FIELD_FROM_HS 5.0-7 
SET_FMH7_RC 5.1-57 


PS.SPS 


See also presentation services for syne 
point services (PS.SPS) 

See also sync point, manager 

logic 5.3-9, 5.3-16, 5,.3-18, 5.3-20, 
§.3-22, 5.3-25, 5.3-30, 5.3-31, 5.3-32, 
§.3-34, 5.3-35 


PS_SPS procedure 5.3-35 


referenced by 
MC_CONFIRM_PROC 5.2~-21i 
MC_SEND_DATA_PROC 5.2-38 
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MC_SEND_ERROR_PROC 5.2-40 ALLOCATE_RCB_PROC 3-24 


PROCESS DATA_PROC 5.1~-44 CREATE_RCB 3-39 
PROCESS_ERROR_OR_FAILURE_RC 5.2-31 RCB_ALLOCATED_PROC 5.1-48 
PS_VERB_ROUTER 5.0-11 TEST_FOR_FREE_FSP_SESSION 3-65 
PS_TO_HS_RECORD structure A-24 RCB_DEALLOCATED structure A-33 
referenced by referenced b 
DFC_SEND_FROM_PS 6.1-19 PROCESS_PS_TO_RM_RECORD 3-21 
PREPARE_TO_RECEIVE FLUSH_PROC 5.1-43 RCB_ID structure 3-74 
PS_TO_RM_RECORD structure A-25 referenced by 
referenced by ATTACH_PROC 3-27 
PROCESS_PS_TO_RM_RECORD 3-21 COMPLETE_HS_ATTACH 3-38 
PS Usage field CONNECT _RCB_ANO_SCB 3-39 
in BIND 4-22 DEALLOCATION_CLEANUP_PROC 5.0-13 
PS_VERB_ROUTER procedure 5.0-11 PS PROTOCOL_ERROR 5.0-15 
referenced by SET_RCB_AND_SCB_FIELDS 3-61 
GET_SEND_INDICATOR 5.2-44 RCB_LIST_PTR structure 5.0-20 
MC_ALLOCATE_PROC 5.2-20 referenced by 
MC_CONFIRM_PROC 5.2-21 PS 5.0-5 
MC_CONFIRMED_PROC 5.2-22 RCB structure A-7 
MC_DEALLOCATE_PROC 5.2-23 referenced by 
MC_FLUSH_PROC 5.2-23 ATTACH_ERROR_PROC 5.0-10 
MC_PREPARE_TO_RECEIVE_PROC 5.2-26 BID_RSP_PROC 3-32 
MC_REQUEST_TO_SEND_PROC 5.2-37 BIDDER_PROC 3-34 
MC_SEND_DATA_PROC 5.2-38 COMPLETE_CONFIRM_PROC 5.1-29 
MC_SEND_ERROR_PROC 5.2-40 COMPLETE_DEALLOCATE_ABEND_PROC 5.1-30 
MC_TEST_PROC 5.2-28 CONFIRM_PROC 5.1-12 
PROCESS _DATA_INCOMPLETE 5.2-36 CONFIRMED _PROC 5.1-14 
PROTOCOL_ERROR_PROC 5.2-47 CONVERSATION_FAILURE_ PROC 5.1-31 
RCVD_SVC_ERROR_PURGING 5.2-42 CREATE_RCB 3-39 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC 5.2-41 DEALLOCATE_ABEND_PROC 5.1-32 
SEND_SVC_ERROR_PURGING 5.2-45 DEALLOCATE_CONFIRM_PROC 5.1-33 
PU (physical unit) 1-3, 2-16, 2-36 DEALLOCATE_FLUSH_PROC 5.1-35 
peripheral 1-5 DEALLOCATE_PROC 5.1-15 
protocol boundary to LU 2-49 DEALLOCATION_CLEANUP_PROC 5.0-13 
relationship to LU 2-18, 2-28, 2-37, 2-45 DEQUEUVE_FMH7_PROC 5.1-36 
subarea 1-5 FIRST_SPEAKER_PROC 3-43 
PU type 1-5 FLUSH_PROC 5.1-17 
corresponding to node type 1-5 FREE_SESSION_PROC 3-44 
purging of chains 2-12, 2-15, 6.1-1 FSM_CONVERSATION 5.1-63 


FSM_ERROR_OR_FAILURE 5.1-65 
3 GET_ATTRIBUTES_PROC 5.1-18 
| | GET_END_CHAIN FROM_HS 5.1-37 
[2 | GET_SENO_INDICATOR 5.2-44 
GET_SESSION_PROC 3-45 
INITIALIZE_ATTACHED_RCB 5.0-16 


QRI MC_ALLOCATE PROC 5.2-20 
See Queued Response indicator (QRI) MC_CONFIRM_PROC 5.2-21 
queue 2-4 MC_DEALLOCATE_PROC 5.2-23 
See also SEND/RECEIVE process interaction MC_POST_ON_RECEIPT_PROC 5.2-25 
Queued Response indicator (QRI) 6.2-6 MC_PREPARE_TO_RECEIVE_PROC 5.2-26 
use 6.1-9, 6.1-10 MC_RECEIVE AND _WAIT_PROC 5.2-27 
queuing of session initiation RUs MC_SEND_DATA_PROC 5.2~-38 
determination using NOTIFY(Vector Key MC_SEND_ERROR_PROC 5.2-40 
X'0C') 4-14 MC_TEST_PROC 5.2-28 
INIT-SELF 4-9 OBTAIN_SESSION_PROC 5.1-38 


PERFORM_RECEIVE PROCESSING 5.1-39 
POST_AND_WAIT_ PROC 5.1-40 
POST_ON_RECEIPT_PROC 5.1-18 

[| PREPARE _TO_RECEIVE_CONFIRM_PROC 5.1-41 
PREPARE _TO_RECEIVE_FLUSH_PROC 5.1-43 
PREPARE TO_RECEIVE PROC 5.1-19 


random data 4-24, 4-27 PROCESS DATA_COMPLETE 5.2~33 
See also LU-LU verification | PROCESS DATA_INCOMPLETE 5.2-36 
See also session-level security, random PROCESS _DATA_PROC 5.1-44 
data PROCESS ERROR_OR_FAILURE_RC 5.2-3) 
Random Data Structured Data Subfield E-17 PROCESS _FMH7_PROC 5.1-46 
RCB PROCESS MAPPER_RETURN_CODE 5.2-35 
See resource control block (RCB) PROCESS _PS_TO_RM_RECORD 3-21 
RCB_ALLOCATED_PROC procedure 5.1-48 PROCESS_RM_OR_HS TO_PS_RECORDS 5.1-47 
referenced by PROTOCOL_ERROR_PROC 5.2-47 
ALLOCATE_PROC 5.1-11 PS_CREATION_PROC 3-47 
RCB_ALLOCATED structure A-32 PS_INITIALIZE 5.0-6 
referenced by e 4 PS_VERB_ROUTER 5.0-11 
ALLOCATE PROC 5.1-11 RCB_ALLOCATED_PROC 5.1-48 


Index X-21 


X-22 


RCVD_SVC_ERROR_PURGING 5.2-42 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC 5.2-41 
RECEIVE_AND_WAIT_PROC 5.1-20 
RECEIVE _DATA_PROCESSING 5.1-50 
RECEIVE_IMMEDIATE_PROC 5.1-22 
RECEIVE_INFO_PROC 5.2-30 
RECEIVE PIP_FIELD_FROM_HS 5.0-7 
RECEIVE_RM_OR_HS_TO_PS_RECORD 5.1-51 
REQUEST_TO_SEND_PROC 5.1-23 
SEND_DATA_BUFFER_MANAGEMENT 5.1-51 
SEND_DATA_PROC 5.1-24 
SEND DATA_ TO_LHS PROC 5.1-52 
SEND_ERROR_ DONE_ PROC 5.1-53 
SEND ERROR_IN_RECEIVE_STATE 5.1-54 
SEND_ERROR_IN_SEND_STATE 5.1-55 
SEND_ERROR_PROC 5.1~26 
SEND_ERROR_TO_HS_PROC 5.1-56 
SEND_SVC_ERROR_PURGING 5.2-45 
SESSION_ACTIVATED_ALLOCATION 3-56 
SESSION_DEACTIVATED_PROC 3-58 
SET_FMH7_RC 5.1-57 
SET_RCB_ AND _SCB_FIELDS 3-61 
TEST FOR_ FREE_ FSP_ SESSION 3-65 
TEST_FoR_ POST_ SATISFIED 5.1-58 
TEST_FOR _RESOURCE_ POSTED 5.0-17 
TEST_PROC 5.1-27 
WAIT _FOR_CONFIRNED_ PROC 5.1-59 
WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 5.1-61 
WAIT_FOR_ SEND_ ERROR_DONE_ PROC 5.1-62 
WAIT_ PROC 5. 0-13 
RCV_STATE_ERROR procedure 6.1-36 
referenced by 
DFC_RCV_FSMS 6.1-24 
RCVD_SVC_ERROR_PURGING procedure 5.2-42 
referenced by 
MC_CONFIRM_PROC 5.2-21 
MC_DEALLOCATE_PROC 5.2-23 
MC_PREPARE_TO_RECEIVE_PROC 5.2-26 
MC_SEND_DATA_PROC 5.2-38 
MC_SEND_ERROR_PROC 5.2-40 
PROCESS_ERROR_OR_FAILURE_RC 5.2-31 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC proce- 
dure 5.2-41 
referenced by 
PROCESS _DATA_INCOMPLETE 5.2-36 
PROCESS_ERROR_OR_FAILURE_ RC 5.2-31 
READY TO RECEIVE (RTR) 3-10, 6.1-2, 6.1-4, 
6.1-5, 6.1-7, 6.1-9, 6.1-10, 6.1-12, 6.1- 13, 
6.1-15, E-13 
reblocking 2-14, 2-16, 2-32 
RECEIVE_AND_WAIT_PROC procedure 5.1-20 
referenced by 
PS_ CONV 5.1-10 
receive check 5.1-9 
sense data included with 6-1 
RECEIVE _DATA_PROCESSING procedure 5.1-50 
referenced by 
PROCESS_DATA_PROC 5.1-44 
RECEIVE DATA structure A-12 
referenced by 
GET_END_CHAIN_FROM_HS 5.1-37 
PROCESS_RU_DATA 6.1-34 
RECEIVE ERROR structure A~-12 
referenced by 
DEALLOCATE _FLUSH_ PROC 5.1-35 
PREPARE_TO_| - RECEIVE _CONFIRM_ PROC 5.1-41 
PREPARE_TO_RECEIVE_FLUSH_PROC 5.1-43 
RECEIVE_AND_WAIT_PROC 5.1-20 
RECEIVE _IMMEDIATE_PROC 5.1-22 
SEND_DATA_PROC 5. 1-24 
SEND_RSP_TO_RM_OR_PS 6.1-39 
RECEIVE _IMMEDIATE_PROC precedure 5.1-22 
referenced by 
PS CONV 5.1-10 


iif { 


RECEIVE _INFO_PROC procedure 5.2-30 
raterenced by 
MC_RECEIVE_AND_WAIT_PROC 5.2-27 
MC_TEST_PROC 5.2-28 
RECEIVE PIP_FIELD_FROM_HS procedure 5.0-7 
referenced by 
PS_INITIALIZE 5.0-6 
RECEIVE _RM_OR_HS_TO_PS_RECORD proce- 
dure 5.1-51 
referenced by 
GET_END_CHAIN_FROM_HS 5.1-37 
PROCESS RM_OR_HS_TO_PS_ RECORDS 5.1-47 
WAIT_FOR_CONFIRMED_PROC 5.1-59 
WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC 5.1-61 
RECEIVED_INFO structure A-8 
receiving data 2-32 
recovery 
See errors and failures 
recursion in PS 2-31, 2-32 
remote, role of LU and TP 2-5, 2-42 
reply in HDX-FF protocol 
See send/receive mode, half-chplex 
flip-flop (HDX-FF) 
REQECHO E-13 
See also REQUEST ECHO TEST 
Request Comnit 
See sync point, commands, Request Commit 
request control mode 6.2-6 
See also control mode 
immediate request mode 6.1-8 
REQUEST ECHO (REQECHO) 4-31 
REQUEST ECHO TEST (REQECHO) 4-31, E-13 
request/response correlation 6.1-1, 6.1-8 
request/response header (RH) 2-15, 2-16, 
2-20, 2-32, D-1, D-2 
discussion of bit usage and val- 
ves D-1-D-4 
format and bit settings D-2 
Format indicator (FI} H-4 
relationship to verbs 2-19 
session control 6.2-3 
request/response wumits (RUs) 2-15 
See also individual RUs 
character-coded 4-2 
field-formatted 4-2 
LU-LU session initiation 4-7 
LU-LU session status notification 4-7 
LU-LU session termination 4-7 
maintenance services 4-29 
maximum size 2-8, 2-16, 2-32, 2-42, 6.2-5 
session control 4-15 
session services 4-7 
REQUEST_TO_SEND_PROC procedure 5.1-23 
referenced by 
-PS_CONV 5.1-10 


_ REQUEST_TO_SEND structure A-13, A-26 


referenced by 
DFC_SEND_FROM., PS 6.1-19 
REQUEST_ TO_ SEND_ PROC 5.1-23 
TRY_TO_RCV_SIGNAL 6.1-22 
request unit (RU) 
FM headers in H-4 
RESET_NORMAL structure 4-101 
RESET_SESSION_LIMIT_PROC procedure 5.4-34 
referenced by 
PS_COPR 5.4-32 
RESET_SESSION_LIMIT verb 5.4-6, 5.4-20 
processing by PS.COPR 
all mode names 5.4-6, 5.4-27, 5.4-28, 
~~ 8. 4-30 
parallel-session mode name 5.4-30 
single-session mode name 5.4-25 
: SNASVCMG mode name 5.4-25 
RESET_SON structure 4-161 
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resource 2-3, 2-45 
dynamic 2-42 
function-shipped 
local 2-4 
network, LU-accessed 2-3, 2-4, 2-38, 
2-42, 2-46, 5.4-1, 5.4-3, 5.4-5 
control point 
local LU 5.4-5 
mode 5.4-5 
partner LU 5.4-5 
transaction program 5.4-5 
posting 5.0-4, 5.1-7 
protected 2-4, 2-39 
resource control block (RCB) 5.2-4, 2-45, 
3-3, 5.0-3, 5.1-3, 5.2-4, 5.3-7, 5.3-8, 
5.3-18, 5.3-20 
resource ID 2-6 
resources manager (RM) 2-40, 3-1 
function summary 2-37, 3-2 
process 2-45 
protocol] boundaries 2-49, 2-50 
protocol boundary 3-2 
resources, local 
See sync point, local resources 
response control mode 6.2-6 
See also control mode 
immediate response mode 6.1-8 
response correlation 2-32 
response to chain 
See request/response units (RUs ) 
responsible parameter 3-16 
See also session, deactivation, responsi- 
bility 
negotiation by CNOS 5.4-30 
RESULT_CHECK_ALLOCATE procedure 5.4-52 
referenced b 
SOURCE_CONVERSATION 5.4-50 
RESULT_CHECK_RECEIVE_COMMAND proce- 
dure 5.4-61 
referenced by 
TARGET _COMMAND_CONVERSATION 5.4-60 
RESULT_CHECK_RECEIVE_DEALLOCATE proce- 
dure 5.4-55 
referenced by 
SOURCE_CONVERSATION 5.4-50 
RESULT_CHECK_RECEIVE_REPLY procedure 5.4-54 
referenced by 
SOURCE_CONVERSATION 5.4-50 
RESULT_CHECK_RECEIVE_SEND procedure 5.4-62 
referenced by 
TARGET_COMMAND_CONVERSATION 5.4-60 
RESULT_CHECK_SEND_COMMAND procedure 5.4-53 
referenced by 
SOURCE_CONVERSATION 5.4-50 
RESULT_CHECK_SEND_REPLY procedure 5.4-66 
referenced by 
TARGET_COMMAND_CONVERSATION 5.4-60 
TARGET_REPLY_CONVERSATION 5.4-65 
resyne service transaction program 
See sync point, resynchronization 
resynchronization 
See sync point 
return | 
See CALL/RETURN procedure interaction 
RETURN_CODE structure 5.0-19 
referenced by 
TEST_FOR_RESOURCE_POSTED 5.0-17 
WAIT_PROC 5.0-13 
RH 
See request/response header (RH) 


RM 


See resources manager (RM) 
RM_ACTIVATE_SESSION_PROC procedure 3-48 
referenced by 


PROCESS _ PS _TO_RM_RECORD 3-21 
RM_ACTIVATE_SESSION structure A-27 
referenced by 
ACTIVATE_SESSION_PROC 5.4-36 
RM_ACTIVATE_SESSION_PROC 3-48 
SUCCESSFUL_SESSION_ACTIVATION 3-63 
RM_DEACTIVATE_SESSION_PROC procedure 3-49 
referenced by 
CTERM_DEACTIVATE_SESSION_PROC 3-40 
PROCESS_PS_TO_RM_RECORD 3-21 
RM_DEACTIVATE_SESSION structure A-27 
referenced by 
CTERM_DEACTIVATE_SESSION_PROC 3-40 
DEACTIVATE_SESSION_PROC 5.4-37 
RM_DEACTIVATE_SESSION_PROC 3-49 
RM process 3-18 
referenced by 
ACTIVATE_SESSION_PROC 5.4-36 
ALLOCATE_PROC 5.1-11 
CHANGE_ACTION 5&.4-44 
DEACTIVATE_SESSION_PROC 5.4-37 
FLUSH _ PROC 5.1-17 
FSM_ERROR_OR_FAILURE 5.1-65 
PROCESS_RM_OR_HS_TO_PS_RECORDS 5.1-47 
RECEIVE _RM_OR_HS_TO_PS_RECORD 5.1-51 
WAIT_FOR_CONFIRMNED_PROC 5.1~-59 
WAIT _FOR_RM_REPLY 5.1-60 
RM_PROTOCOL_ERROR procedure 3-49 
referenced by 
ATTACH_PROC 3-27 
BID_PROC 3-30 
FREE_SESSION_PROC 3-44 
FSM_BIS_BIODDER 3-70 
FSM_BIS_FSP 3-71 
RTR_RQ PROC 3-50 
SECURITY_PROC 3-52 
UNBIND_PROTOCOL_ERROR_PROC 3-65 
RM_SESSION_ACTIVATED structure A-33 
referenced by 
ACTIVATE_SESSION_PROC 5.4-36 
RM_ACTIVATE_SESSION PROC 3-48 
SESSION_DEACTIVATED_PROC 3-58 
SUCCESSFUL_SESSION_ACTIVATION 3-63 
UNSUCCESSFUL_SESSION_ACTIVATION 3-66 
RM_TO_HS_RECORD structure A-28 
referenced by 
DFC_SEND_FROM_RM 6.1-20 
RM_TO_LNS_RECORD structure A-3l1 
referenced by 
LNS 4-47 | 
PROCESS_RECORD_FROM_RM 4-48 
RM_TO_PS_RECORD structure A-32 
referenced by 
PROCESS RM_OR_HS TO_PS_RECORDS 5.1-47 
WAIT_FOR_CONFIRMED_PROC 5.1-59 
WAIT_FOR_RM_REPLY 5.1-60 
role of LU and TP 2-5 
route 2-42 
routing and checking logic, representation 
within the formal description 
RSP_TO_REQUEST_TO_SEND structure A-13 
referenced by 
DFC_RCV_FSMS 6.1~-24 
RSP(ACTLU) 4-17, E-18 
RSP(BIND) 4-25, E-19 
RSP(CINIT) 4-10, E-19 
RTR E-13 
See also READY TO RECEIVE 
RTR (READY TO RECEIVE) 6.1-15 
RTR_RQ_PROC procedure 3-50 
referenced by 
PROCESS_HS TO _RM_RECORD 3-19 
RTR_RQ structure A-15, A-30 
referenced by 


Index X-23 


X-24 


FREE_SESSION_PROC 3-44 
GENERATE_RM_PS_INPUTS 6.1-31 
RTR_RQ_PROC 3-50 

RTR_RSP_PROC procedure 3-51 

referenced by | 
PROCESS_HS_TO_RM_RECORD 3-19 
RTR_RSP structure A-15, A-30 
referenced by 
GENERATE_RM_PS_INPUTS 6.1-31 
RTR_RQ PROC 3-50 
RTR_RSP_PROC 3-51 
SEND_RSP_TO_RM_OR_PS 6.1-39 
RU 
See request/response units (RUs) 
RU parameters 
implementation-dependent 4-6 
installation-specified 4-6 
specification of 4-6 
used by LU network services 4-5 
rule 1 (conditional termination) 
See bracket, bracket termination rule 


Ka 


SCB structure A-9 
referenced by 
- ATTACH_PROC 3-27 
COMPLETE_HS_ATTACH 3-38 
CREATE_SCB 3-40 
FREE_SESSION_PROC 3-44 
PROCESS_HS_TO_RM_RECORD 3-19 
SECURITY_PROC 3-52 
SEND_DEACTIVATE_SESSION 3-55 
SESSION _DEACTIVATED_PROC 3-58 
SET_RCB_AND_SCB_FIELDS 3-61 
SUCCESSFUL_SESSION_ACTIVATION 3-63 
secondary LU (SLU) 2-36, 4-4 
See also session, activation polarity 
secondary LU name 
in BIND 4-25 
security 2-10, 2-13 
See also conversation-level security 
See also session cryptography 
See also session-level security 
security dosngrade 
See conversation-level security 
Security FM header 4-6 
See also FM header, type 12 (Security) 
SECURITY_HEADER structure A-15 
referenced by 
PROCESS _RU_DATA 6.1-34 
 SECURITY_PROC 3-52 
SECURITY_PROC procedure 3-52 
referenced by 
PROCESS_HS_TO_RM_RECORD 3-19 
SEND_ACTIVATE_SESSION procedure 3-52 
referenced by 
ACTIVATE_NEEDED_SESSIONS 3-22 
GET SESSION_PROC 3-45. 
RM_ACTIVATE_SESSION_PROC 3-48 
SEND_BIS procedure 3-53 
referenced by 
DEACTIVATE_FREE_SESSIONS 3-41 
FREE_SESSION_PROC 3-44 
RTR_RQ_ PROC 3-50 
RTR_RSP_PROC 3-51 
SEND_BIS_ REPLY procedure 3-53 
referenced by 
CHECK_FOR_BIS_REPLY 3-38 
. SEND_BIS 3-53 | 
SEND_BIS_RQ procedure 3-54 


referenced by 
BIS_RACE_LOSER 3-35 
RM_DEACTIVATE_SESSION_PROC 3-49 
) SEND_BIS 3-53 | 
SEND_BIU procedure 6.1-37 
referenced by 
PROCESS_SEND_PARM 6.1-35 
SEND_BUFFER structure 5,2-48 
referenced by 
MC_SEND_DATA_PROC 5.2-38 
send check 
sense data included with 6-1 
SEND_DATA_BUFFER_MANAGEMENT procedure 5.1-51 
referenced by 
ATTACH_ERROR_PROC 5.0-10 
COMPLETE_DEALLOCATE_ABEND_PROC 5.1-30 
SEND_DATA_PROC 5.1-24 
SEND_ERROR_DONE_PROC 5.1-53 
SEND_DATA_PROC procedure 5.1-24 
referenced by 
PS_CONV 5.1-10 
SEND_DATA_RECORD structure A-24 
referenced by 
COMPLETE_CONFIRM_PROC 5.1-29 
COMPLETE _DEALLOCATE_ABEND_PROC 5.1-30 
DEALLOCATE_CONFIRM_PROC 5.1~-33 
DEALLOCATE_FLUSH_PROC 5.1-35 
DFC_SEND_FROM_PS 6.1-19 
PREPARE_TO_RECEIVE_CONFIRM_PROC 5.1-41 
RECEIVE_AND_WAIT_PROC 5.1-20 
SEND_DATA_TO_HS_PROC 5.1-52 
SEND_DATA_TO_HS_PROC procedure 5.1-52 
referenced by 
ATTACH_ERROR_PROC 5.0-10 
COMPLETE_CONFIRM_PROC 5.1-29 
COMPLETE_DEALLOCATE_ABEND_PROC 5.1-30 
CONFIRM_PROC 5.1-12 
DEALLOCATE_CONFIRM_PROC 5.1-33 
DEALLOCATE_FLUSH_PROC 5.1-35 
FLUSH_PROC 5.1-17 
FSM_CONVERSATION 5.1-63 | 
PREPARE_TO_RECEIVE _CONFIRM_PROC 5.1-41 
PREPARE_TO_RECEIVE_FLUSH_ PROC 5.1-43 
RCB_ALLOCATED_PROC 5.1-48 
RECEIVE_AND WAIT PROC 5.1-20 
SEND_DATA_BUFFER_MANAGEMENT 5.1-51 
SEND_DATA_PROC 5.1-24 
SEND_ERROR_DONE_PROC 5.1-53 
SEND_ERROR_IN_SEND_STATE 5.1-55 
SEND_DEACTIVATE_SESSION procedure 3-55 
referenced by 
BID_RSP_PROC 3-32 
DEACTIVATE_PENDING_ SESSIONS 3-41 
FSM_BIS_BIDDER 3-70 
FSM_BIS_FSP 3-71 
RM_DEACTIVATE_SESSION_PROC 3-49 
RM_PROTOCOL_ERROR 3-49 
SEND_ERROR_DONE_PROC procedure 5.1~-53 
referenced by 
SEND_ERROR_IN_SEND_STATE 5.1-55 
SEND_ERROR_PROC 5.1~-26 
WAIT_FOR_SEND_ERROR_DONE_PROC 5.1-62 
SEND_ERROR_IN_ RECEIVE STATE procedure 5.1-54 
referenced by 
SEND_ERROR_PROC 5.1-26 
SEND_ERROR_IN_SEND_STATE procedure 5.1-55 
referenced by 
SEND_ERROR_PROC 5.1-26 
SEND_ERROR_PROC procedure 5.1-26 
referenced by 
PS CONV 5.1-10 
SEND_ERROR structure A-24 
referenced by 
DEALLOCATE_ABEND_PROC 5.1~-32 


SNA Format and Protocol Reference Manual for LU Type 6.2 


DFC_SEND_FROM_PS 6.1-19 
SEND_ERROR_IN_RECEIVE_STATE 5.1-54 
SEND_ERROR PROC 5.1-26 
SEND_ERROR_TO_HS_PROC 5.1-56 
SEND_ERROR_TO_HS_PROC procedure 5.1-56 
referenced by 
ATTACH_ERROR_PROC 5.0-10 
SEND_NEG_RSP_OR_LOG procedure 6.1-37 
referenced by 
DFC_RCV 6.1-23 
TC.RCV 6.2-15 
SEND_PARM structure A-36 
referenced by 
PROCESS SEND_PARM 6.1-35 
send/receive concurrency 2-6 
send/receive mode 
full-duplex (FDX) 6.1-16 
half-duplex flip-flop (HDX-FF) 6.1-1, 
6.1-3, 6.1-10 
SEND/RECEIVE process interaction 2-45 
send/receive state of conversation 2-6, 
2-31, 2-34, 2-35 
See also half-duplex flip-flop 
send/receive mode 
SEND_RSP_BIU procedure 6.1-38 
referenced by 
DFC_RCV 6.1-23 
DFC_RCV_FSMS 6.1-24 
DFC_SEND_FROM_PS 6.1-19 
GENERATE_RM_PS_ INPUTS 6.1-31 
SEND_RSP_TO_RM_OR_PS procedure 6.1-39 
referenced by 
DFC_RCV_FSMS 6.1-24 
SEND_SVC_ERROR_PURGING procedure 5.2-45 
referenced by 
PROCESS _DATA_COMPLETE 5.2-33 
PROCESS _MAPPER_RETURN_CODE 5.2-35 
sending data 2-31 
sense code 
See sense data 
sense-code specific information 6-1 
SENSE_CODE structure 3-75 
referenced by 
RM_PROTOCOL_ERROR 3-49 
SEND_DEACTIVATE_SESSION 3-55 
sense data 6-1 
format of 6-1 
in FMH-7 2-20 
sense code 
category X'00' (user sense data 


only) 6-1 
category X'08' (request reject) 6-1, 
6-1 
category X‘'10' (request error) 6-5, 
6-1 


category X'20' (state error) 6-6, 6-1 
category X'40° (RH usage error) 6-7, 


6-1 
category X'80" (path error) 6-8), 6-1 
modifier 6-1 


modifier value of X'00' 6-1 
sense-code specific information 6-1 
user-defined data 6-1 

SENSE_DATA structure 5.0-21 
referenced by 

ATTACH_ERROR_PROC 5.0-10 

PS ATTACH CHECK 5.0-8 

PS_INITIALIZE 5.0-6 

PS PROTOCOL_ERROR 5.0-15 

sequence mumbers and IDs 
use in data flow control 6.1-4 
sequence numbers, TH 2-16, 2-32, 6.2-5 
checking 6.2-1 
expedited flow 6.2-5 


identifiers 6.2-5 
initialization 6.2-2, 6.2-5 
normal flow 6.2-5 

TC 6.2-4 

wrapping 6.2-5 


service component 
service transaction program 2-3, 2-38 


See also transaction program 
CNOS 2-3 
DIA 2-3 
resynec (X'06F2' ) 
See sync point, resynchronization 
resynchronization 2-3 
SNADS 2-3, 2-7 


SESSEND E-13 


See also SESSION ENDED 


session 2-1, 2-3 


See also CP-LU session 
activation 2-8, 2-35, 2-36, 2-38, 2-47, 
5.4-4, 5.4-8 
CP-LU 4-2, 4-17 
LU-LU 4-3, 4-19 
newly active session 2-35 
relation to PS.COPR 5.4-8 
activation polarity 2-8 
allocation to conversation 2-7, 2-35, 3-4 
session selection 2-7, 2-35, 3-5 
contention polarity 2-8, 2-35, 5.4-3, 
5.4-8 
See also session limits, minimum con- 
tention wimer 
processing by PS.COPR--mode name 
SNASVCMG session 5.4-25 
processing by PS.COPR--single ses- 
sion 5.4-25 
cryptography 4-10 
See also cryptography key, session 
deactivation 2-8), 2-32, 2-37) 2-38), 2-47, 
5.4-4, 5.4-8 
CP-LU 4-2, 4-19 
LU-LU 4-3, 4-28 
operator controlled 2-36 
relation to PS.COPR 5.4-8, 5.4-25 
responsibility 5.4-5, 5.4-8, 5.4-2l1, 
5 .4-28 
specific session 2-36 
identification 5.4-3 
See also identification of session 
initiation 2-8, 2-16, 2-36, 5.4-4 
initiation, LU-LU 4-3 
failure notification using NOTI- 
FY(Vector Key X'03') 4-14 
key 4-5 
content 4-5 
LU-LU 
activation 3-13 
multiplicity 2-7 : 
parallel 2-1, 2-7, 5.4-3, 5.4-20 
shutdown 2-8, 2-36, 5.4-4, 5.4-8 
single 2-7, 5.4-3, 5.4-20 
state 2-32 
termination 2-8, 5.4-4 
termination, LU-LU 4-3 
failure notification using NOTI- 
FY(Vector Key X’03') 4-14 
type, for termination 
implied by CLEANUP 4-12 
specified in CTERM 4-12 
specified in TERM-SELF 4-12 


SESSION_ACTIVATED_ALLOCATION procedure 3-56 


referenced by 
SUCCESSFUL_SESSION_ACTIVATION 3-63 


SESSION_ACTIVATED_PROC procedure 3-57 


referenced by 


Index X-25 


X-26 


PROCESS _LNS_TO_RM_RECORD 3-20 
SESSION_ACTIVATED structure A-20 
referenced by 
BUILD_AND_SEND_SESS_ACTIVATED 4-67 
SESSION_ACTIVATED_PROC 3-57 
SESSION_ACTIVATION_POLARITY procedure 3-57 
referenced by 
ACTIVATE_NEEDED_SESSIONS 3-22 
GET_SESSION_PROC 3-45 
RM_ACTIVATE_SESSION_PROC 3-48 
SESSION_ALLOCATED structure A-33 
referenced by 
BID_RSP_PROC 3-32 
CHANGE_ SESSIONS__ PROC 3-37 
FIRST_ SPEAKER_ PROC 3-43 
GET_SESSION_PROC 3-45 
OBTAIN _SESSION_PROC 5.1~-38 
SEND_DEACTIVATE_SESSION 3-55 
SESSION_ACTIVATED_ALLOCATION 3-56 
SESSION_DEACTIVATED_PROC 3-58 
SUCCESSFUL_SESSION_ACTIVATION 3-63 
UNSUCCESSFUL_SESSION_ACTIVATION 3-66 
session control block (SCB) 3-3 
session control RUs 2-18), 2-36, 2-45 
ACTLU 4-17 
BIND 4-19 
CRV 6.2-2s 6.2-3 
DACTLU 4-19 
RH 6.2-3 F 
RSPCACTLU) 4-17 
RSP(BIND) 4-25 
TH 6.2-3 
UNBIND 4-28 
session counts 5.4-4, 5.4-8 
See also session Limits 
relationship to CNOS 5.4-6, 5.4-28 
termination count 3-16, 5.4-5, 5.4-8 
session cryptography 2-10, 2-11, 2-32, 2-36, 
2-42 
key 2-11, 2-36 
session seed 2-Il 
verification 2-36 
SESSION_DEACTIVATED_PROC procedure 3-58 
referenced by 
PROCESS_LNS_TO_RM_RECORD 3-20 
SEND_DEACTIVATE_SESSION 3-55 
SESSION_DEACTIVATED structure A-2l 
referenced by 
BUILD_AND_SEND_SESS_DEACTIVATED 4-67 
SEND_DEACTIVATE_SESSION 3-55 
SESSION_DEACTIVATED_PROC 3-58 
SESSION_DEACTIVATION_POLARITY procedure 3-60 
referenced by 
BIS_RACE_LOSER 3-35 
DEACTIVATE_FREE_SESSIONS 3-41 
DEACTIVATE_PENDING_SESSIONS 3-41 
SHOULD_SEND_BIS 3-62 
SESSION ENDED (SESSEND) 4-13, E-13 
SESSION_INFORMATION structure A-36 
referenced by 
CREATE_SCB 3-40 
SUCCESSFUL__ SESSION_ACTIVATION 3-63 
session initiation RUs 4-7 
BINDF 4-11 
CINIT 4-9 
INIT-SELF 4-9 
RSP(CINIT) 4-10 
SESSST 4-11 
Session Instance Identifier Structured Data 
Subfield E-16 
Session Key 
Network Address Pair E- 23 
Network Name Pair E~-23 
Network-Qualified Address Pair E-23 


Uninterpreted Name E-23. 
URC E-23 : 
Session Keys 
table of E-23 
session-level pacing 2-8, 2-32, 6.2-1, 6.2-5 
deadlock 6.2-6 
FSM_PAC_RQ._ RCV 6.2-21 
FSM_PAC_RQ SEND 6.2-20 
IPR 6.2-6 
pacing count 6.2-6 
pacing queue 6.2-6 
parameter set up 6.2-2 
PI 6.2-5, 6.2-6 | 
Queued Response indicator (QRI) 6.2-6 
response 2-8, 2-32 
stages 6.2-5 
window 2-8, 2-32 
window size 2-3, 2-8) 2-42, 6.2-5 
session-level security 2-10, 2-35, 2-36, 
2-37, 3-14 
DES (Data Encryption Standard) 2-10 
enciphered data 2-10, 2-36 
FMH-12 H-9 7 
See also FM header, type 12 (Security) 
LU-LU password 2-10, 2-36 
LU-LU verification 2-10, 2-37, 2-38, 3-2; 
3-14 
LU-LU verification sequence 2-10 
physical security 2-11. 
random data 2-10, 2-36 
SESSION_LIMIT_DATA_LOCK MANAGER proce- 
dure 5.4-67 
referenced by 
PROCESS SESSION_LIMIT_PROC 5.4-58 
SOURCE_SESSION_LIMIT_PROC 5.4-46 
session limits 2-8) 3-14, 3-15, 5.4-4, 5.4-8 
automatic activation 2-8) 2-36, 3-15, 
3-16, 5.4-4, 5.4-8 © 
initialization 2-8, 2-35, 2-38), 2-46, 
5.4-4 
LU-mode 2-8, 5.4-4, 5.4-8 
minimum contention winner 2-8, 3-15, 
5.4-4, 5.4-8, 5.4-2], 5.4-25 
negotiation by CNOS 5.4-7, 5.4-28 
reset 2-8, 2-36, 2-47, 5.4-4. 
total LU-LU 2-8, 5.4-4 
session outage 3-17 
See also errors and failures 
session outage notification (SON) 2-12, 
2-36, 4-4 
See also errors, ssnvareetion failure 
CNOS recovery 5.4-20 
See also error recovery, CNOS, conver- 
sation failure 
session pool 2-7 
See also session, allocation to conversa- 
tion 
SESSION_ROUTE_INOP structure A-23 
referenced by 
PROCESS_RECORD_FROM_NNM 4-50 
PROCESS_SESSION_ROUTE_INOP 4-90 
session seed 6.2-2 
session services capabilities 
conveyed in NOTIFY(Vector Key X'0C') 4-14 
conveyed in RSP(ACTLU) 4-16 
session services RUs 2-16, 2-36) 2-42, 4-7, 
4-15 
BINDF 4-11 
CINIT 4-9 
CLEANUP 4-12 
CTERM 4-12 
for reporting status 4-7 
for session initiation 4-7 
for session termination 4-7 
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INIT-SELF 4-9 
NOTIFY 4-14 
RSP(CINIT) 4-10 
SESSEND 4-13 
SESSST 4-11 
TERM-SELF 4-11 
UNBINDF 4-13 
SESSION STARTED (SESSST) 4-11, E-13 
session status notification RUs 4-7 
NOTIFY 4-14 
session termination RUs 4-7 
CLEANUP 4-12 
CTERM 4-12 
SESSEND 4-13 
TERM-SELF 4-11 
UNBINDF 4-13 
SESSION_TYPE structure 4-101 
referenced by 
BIND_RQ_STATE_ERROR 4-52 
CINIT_RQ_STATE_ERROR 4-71 
SESSST E-13 
See also SESSION STARTED 
SET_FMH7_RC procedure 5§.1-57 
referenced by 
PROCESS_FMH7_PROC 5.1-46 
SET_RCB_AND_SCB_FIELDS procedure 3-61 
referenced by 
BID_RSP_PROC 3-32 
FIRST_SPEAKER_PROC 3-43 
SESSION_ACTIVATED_ALLOCATION 3-56 
TEST_FOR_FREE_FSP_SESSION 3-65 
sharing sessions 
See session, allocation to conversation 
SHOULD_SEND_BIS procedure 3-62 
referenced by 
FREE_SESSION_PROC 3-44 
RTR_RQ_PROC 3-50 
RTR_RSP_PROC 3-51 
shutdown of LU 2-45 
shutdown of sessions 
See session, shutdown 
SIG E-14 
See also SIGNAL 
SIG (Signal RU) 2-25 
SIG (SIGNAL) 6.1-15 
SIGNAL (SIG) 6.1-2, 6.1-4, 6.1-5, 6.1-6, 
6.1-7, 6.1-12, 6.1-13, 6.1-15, E-14 
Single session 
See session, single 
single session LU 2-7 
See also session, single 
SLU 
See secondary LU (SLU) 
SLU name 
in BIND 4-25 
SNA-defined mode name for CNOS 
(SNASVCNG) 2-465 5&.4-5, 5.4-21, 5.4-27 


SNA Distribution Services (SNADS) 2-7, 2-38 


SNA network, definition of 1-3 
SNA node 1-3, 1-4 

See also node 
SNA product node 1-3, 1-4 

See also node 
SNADS | 
See SNA Distribution Services (SNADS) 
SNASVCMG 

See SNA-defined mode name for CNOS 

(SNASVCMG } 

SNASVCMG_VERB_PARAMETER_CHECK proce- 
dure 5.4-43 — 

referenced by 

LOCAL_SESSION_LIMIT_PROC 5.4-41 

SNF structure 6.0-6 


Software Product Common Level (X'04') Product 
Identifier Subfield E-25 
Software Product Common Name (X‘'06') Product 
Identifier Subfield E-26 
Software Product Customization Date and Time 
{X'09') Product Identifier Subfield E-26 
Software Product Customization Identifier 
(X%'07') Product Identifier Subfield E-26 
Software Product Program Number (X'08') Prod- 
uct Identifier Subfield E-26 
Software Product Serviceable Component Iden- 
tifier (X'02') Product Identifier Sub- 
field E-25 
SON 
See session outage notification (SON) 
SOURCE_CONVERSATION_CONTROL procedure 5.4-49 
referenced by 
SOURCE_SESSION_LIMIT_PROC 5.4~-46 
SOURCE_CONVERSATION procedure 5.4-50 
referenced by 
SOURCE_CONVERSATION_CONTROL 5.4-49 
SOURCE_SESSION_LIMIT_PROC procedure 5.4-46 
referenced by 
CHANGE_SESSION_LIMIT_PROC 5.4-35 
INITIALIZE_SESSION_LIMIT_PROC 5.4~-33 
RESET_SESSION_LINIT_PROC 5.4-34 
source, role of TP and LU 2-5, 5.4-3 
space (X'40') characters 
trailing 
in LU name comparison 5.4-19 
SSCP (system services control point) 1-3, 
4-2 
SSCP-LU Session Capabilities Control Vec- 
tor E-20 
SSCP-mediated sessions 4-2 
startup of LU 2-45 
STATE_ERROR_SSCP_LU procedure 6.1-40 
referenced by 
DFC_RCV 6.1-23 
state name N-! 
state transition N-1 
state-transition matrix N-1 
action codes 
calling result N-1 
calling N-1 
input signal N-1 
next-state indicator N-1! 
initialization N-1 
inputs to N-1 
output actions N-1 
state name N-1 
state transitions N-1 
state, FSM N-1 
statements 
CALL 
finite-state machines N-} 
stray responses 6.1-5 | 
STRAY_RSP procedure 6.1-41 
referenced by 
DFC_RCV 6.1-23 
stray SIGNALs 6.1-5 
Structured Data Subfield 
Enciphered Data E-17 
Fully Qualified PLU Network Name E-16 
Fully Qualified SLU Network Name E-16 
Mode Name E-16 
Random Data E-~-17 
Session Instance Identifier E-16 
Unformatted Data E-16 
structured fields I[-1 
See also general data stream 
subarea 1-4 
subarea LU 1-5 
subarea node 1-4 
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X-28 


See also node 
subarea node to peripheral node communication 
See peripheral node to subarea node commu- 
nication 
subarea node to subarea node communi- 
cation 2-1 | 
See also SSCP-mediated sessions 
subarea PU 1-5 
sublayers of PS 2-4 
SUCCESSFUL_SESSION_ACTIVATION procedure 3-63 
referenced by 
ACTIVATE_SESSION_RSP_PROC 3-23 
SESSION_ACTIVATED_PROC 3-57 
symbol string 
lengths H-2 
lengths chart H-2 
Type-A E-1 
Type-AE E-~! 
Type-G E-1 
Type-GR E-~1 
Type-USS E-1 
types H-! 
sync point 2-4, 2-12, 2-13, 2-39, 5.3-1 
back-out 2-39, 2-40 
commands 5,.3-2 
Backed Out 5.3-3, 5.3-16, 5.3-17, 
5.3-32, 5.3-41 
Committed 5§.3-3, 5.3-9, 5.3-35, 5.3-36 
Compare States 5.3-2, 5.3-7, 5.3-8, 
5.3-9, 5.3-15, 5.3-18, 5.3-20, 5.3-22, 
§.3-25, 5.3-32, 5.3-33, 5.3-34 
Exchange Log Name 5.3-2, 5.3-18, 
§.3-31, 5.3-33, 5.3-34 
Forget 5.3~-3, 5.3-9, 5.3-32, 5.3-35, 
5.3-36 
Heuristic Mixed 5.3-26, 5.3-35, 5.3-37 
implied Forget 5.3-5, 5.3-12, 5.3-30 
Prepare 5.3-3, 5.3-9, 5.3-22, 5.3-35 
Request Commit 5.3-3, 5.3-9, 5.3-22, 
5.3-35, 5.3-36 
conversation resources 5.3-7 
conversation resource protection manag- 
er 5.3-7 
data base update consistency 2-39 
errors during sync point 5.3-9, 5.3-15, 
5.3-20, 5.3-22, 5.3-24, 5.3-32, 5.3-34 
failures and recovery 5.3-24, 5.3-25, 
5.3-30, 5.3-31, 5.3-32, 5.3-33, 5.3-41 
relationships among 5.3-2 
flows 5.3-37, 5.3-39, 5.3-40, 5.3-41 
general case 5.3~-11 
last resource optimization 5.3-5, 
5.3-9, 5.3-13, 5.3-20, 5.3-25, 5.3-32, 
§.3-36, 5.3-38 
no changes optimization 5.3-5, 5.3-14, 
5 .3-36, 5.3-39 
function shipping 5.3-8 
heuristic decision 5.3-15, 5.3-16, 
§.3-18, 5.3-22, 5.3-24, 5.3-25, 5.3-30; 
§.3-32, 5.3-34, 5.3-37 
and lock manager 5.3-16, 5.3-30 
local resources 5.3-5, 5.3-7, 5.3-18, 
5.3-20 
leg 5.3-3, 5.3-6, 5.3-18) 5.3-31 
See also log manager 
forcing 5.3-7, 5.3-8 
logging 2-39, 2-40 
logical unit of work 2-39 
manager 5.3-3, 5.3-25, 5.3-30, 5.3-32, 
5.3-35 ; 
operator messages 5§.3-25, 5.3-30 
phases 
See also sync point, commands 
classification 5.3-9 


presentation services header 
See presentation services (PS) headers 
protection manager 2-40, 5.3-6, 5.3-15, 
§.3-18, 5.3-20 
protocol 2-40 
resynchronization 2-42, 5.3-2, 5.3-15, 
5.3-16, 5.3-18, 5.3-19, 5.3-20, 5.3-22, 
5.3-25, 5.3-30, 5.3-31, 5.3-32, 5.3~-33, 
5.3-34 
roles 5.3-2, 5.3-18, 5.3-22, 5.3-25 
agent 5.3-2, 5.3-3, 5.3-18, 5.3-22 
cascaded agent 5.3-2, 5.3-3, 5.3-18, 
5.3-20, 5.3-28, 5.3-32 
initiator 5.3-2, 5.3-3, 5.3-9, 5,3-18, 
§.3~-32 
structure 2-40 
synchronization point 2-39 
unit of work 
See sync point, logical unit of work 
syne point protocols 
RH bit settings D-4 
synchronized unit of work 
See syne point, logical unit of work 
synchronous transfer 2-6; 2-38 
SYNCPT 
See syne point 
system services control point (SSCP) 
See SSCP (system services control point) 


TARGET_COMMAND_CONVERSATION procedure 5.4-60 
referenced by 
PROCESS SESSION_LIMIT_PROC 5.4-58 
TARGET_REPLY_CONVERSATION procedure 5.4-65 
referenced by 
PROCESS_SESSION_LIMIT_PROC 5.4-58 
target, role of TP and LU 2-5, 5.4-3 
Tc 
See transmission control (TC) 
TC.BUILD_CRV procedure 6.2-11 
referenced by 
TC. EXCHANGE_CRV 6.2-10 
TC .DEQUEUE_PAC procedure 6.2-18 
TC .EXCHANGE_CRV procedure 6.2-10 
referenced by 
TC.INITIALIZE 6.2-8 
TC.FORMAT_CHECK procedure 6.2-11 
referenced by 
TC. .EXCHANGE_ CRV 6.2~-10 
TC.INITIALIZE 6.2-2 
TC.INITIALIZE procedure 6.2~-8 
referenced by 
HS 6.0-3 
TC.RCV_CHECKS procedure 6.2-16 
referenced by 
TC.RCV 6.2-15 
TC.RCV_NORM_RQ procedure 6.2-17 
referenced by 
TC.RCV 6.2-15 
TE.RCV procedure 6.2-15 
referenced by 
PROCESS CP_LU_ SESSION 6.0-5 
PROCESS _LU_LU_SESSION 6.0-4 
TC.SEND procedure 6.2-13 
referenced by 
DOFC_SEND_FROM_LNS 6.1-22 
DFC_SEND_FSMS 6.1-25 
SEND_NEG_RSP_OR_LOG 6.1-37 
TC. TRY_TO_ENCIPHER procedure 6.2-14 
referenced by 
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TC.SEND 6.2-13 
TC.TRY_TO_SEND_IPR 6.2-4, 6.2-19 
TC.TRY_TO_SEND_IPR procedure 6.2-19 
referenced by 
PROCESS_LU_LU_ SESSION 6.0-4 
TCB 
See transaction control block (TCB) 
TCB_ID structure 3-74 
referenced by 
ATTACH PROC 3-27 : 
COMPLETE_HS_ATTACH 3-38 
PS 5.0-5 
TCB_LIST_PTR structure 5.0-20 
referenced by 
PS 5.0-5 
TCB structure A-10 
referenced by 
DEALLOCATION_CLEANUP_PROC 5.0-13 
GET_ATTRIBUTES_PROC 5.1-18 
PROCESS_PS_TO_RM_RECORD 3-21 
PS 5.0-5 
PS_ATTACH_CHECK 5.0-8 
PS_CREATION_PROC 3-47 
PS_INITIALIZE 5.0-6 
PS _VERB_ROUTER 5.0-11 
RCB_ALLOCATED_PROC 5.1-48 
WAIT_PROC 5.0-13 
TCCB 
See transmission control control block 
(TCCB) 
TERM-SELF E-14 
See also TERMINATE-SELF 
TERM-SELF Format 1 
See TERMINATE-SELF 
terminal 2-1, 2-4 
See also peripheral node to subarea node 
communication 
See also resource, local 
TERMINATE_PS structure A-27 
referenced by 
DEALLOCATION_CLEANUP_PROC 5.0-13 
TERMINATE-SELF (TERM-SELF) 4-11, E-14 
terminating LU (TLU) 4-4 
termination count 
See session counts, termination count 
termination rule, bracket 
See bracket, bracket termination rule 
TEST_FOR_FREE_FSP_SESSION procedure 3-65 
referenced by 
ALLOCATE_RCB_PROC 3-24 
TEST_FOR_POST_SATISFIED procedure 5.1-58 
referenced by 
POST_AND_WAIT_PROC 5.1-40 
PROCESS_RM_OR_HS_TO_PS_RECORDS 5.1-47 
TEST_FOR_RESOURCE_POSTED procedure 5.0-17 
referenced by 
WAIT_PROC 5.0-13 
TEST_PROC procedure 5.1-27 
referenced by 
MC_TEST_PROC 5.2-28 
PS CONV 5.1-10 
TEST_FOR_RESOURCE_ POSTED 5.0-17 
TEST structure 5.1-67 
referenced by 
TEST_PROC 5.1-27 
TH 
See transmission header (TH) 
TLU 
See terminating LU (TLU) 
TP 
See transaction program instance 
TP-PS process 
See presentation services (PS), process 
See transaction program, proc:.ss 


TPN 
See transaction program name (TPN) 
transaction control block (TCB) 3-3, 5.0-3;, 
5.1-3, 5.2-4, 5.3-7, 5.3-8) 5.3-18, 5.3-20 
TRANSACTION _PGM_VERB structure 
processing by PS.COPR 5.4-24, 5.4-28 
transaction program 2-1, 2-4, 2-42 
See also transaction program code 
See also transaction program instance 
invoking initial (local) 2-2, 2-34, 2-47, 
3-4 
invoking remote 2-34, 3-4, 3-9 
process 2-42, 2-43, 2-47 
protocol boundary 2-4, 2-28 
See also presentation services for con- 
versations (PS.CONV), protocol bourda- 
ries 
See also presentation services for 
mapped conversations (PS.MC), protocol 
boundaries 
See also presentation services for the 
control operator (PS.COPR), protocol 
boundaries 
terminating 2-35, 5.0-4 
transaction program code 2-34 
See also transaction program 
transaction program instance 2-42 
See also transaction program 
identifying 2-5 
transaction program name (TPN) 2-5, 2-34; 
2-38, 2-42, H-15 
TRANSACTION_PROGRAM structure 2-42, 5.1-1,; 
A-4 
referenced by 
DEFINE _PROC 5.4-36 
DELETE_PROC 5.4-40 
DISPLAY_PROC 5.4-39 
PS_ATTACH_CHECK 5.0-8 
transaction program verbs 2-3, 2-4, 2-31, 
2-49, 5.1-4 
See also basic conversation 
See also presentation services for mapped 
conversations (PS.MC), protocol bounda- 
ries 
See also presentation services for the 
control operator (PS.COPR), protocol 
boundaries 
See also transaction program, protocol 
boundary 
examples 2-19 
GET_TYPE verb 5.0-4% 
issued by LU 2-31, 2-34, 2-38 
parameter checks 5.1-6 
POST_ON_RECEIPT 5.1-7 
REQUEST_TO_SEND 5.1~-7 
SEND_ERROR 5.1-7 
state 5.1-6 
WAIT verb 5.0-4 
transaction services 2-38 
See also transaction program, protocol 
boundary 
transmission control (TC) 
CRV 6.2-2 
initial chaining value 6.2-2, 6.2-3 
session cryptography key 6.2-2 
session seed 6.2-2 
test value 6.2-2 
cryptography 6.2-1, 6.2-4) 6.2-5 
block chaining 6.2-5 
Data Encryption Standard (DES) 6.2-5 
enciphering/deciphering 6.2-1) 6.2-4, 
6.2-5 
initial chaining value 6.2-2, 6.2-3 
session cryptography key 6.2-5 
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session seed 6.2-2 
data traffic protocols 6.2-1 
deadlock 6.2-6 
deciphering 6.2-1, 6.2-4 
enciphering 6.2-1, 6.2-4 
expedited flow 6.2-1, 6.2-4 
HS-initiated procedures 6.2-4 
initial chaining value 6.2-2, 6.2-3 
Isolated Pacing Response (IPR) 6.2-5, 
6.2-6 
normal flow 6.2-4 
pacing 

pacing queue 6.2-6 


Queued Response indicator (QRI) 6.2-6 


session-level 6.2-1 
QRI 6.2-6 
Queued Response indicator (QRI) 6.2-6 
request control mode 6.2-6 
sequence numbers, TH 6.2-4, 6.2-5 
assignment 6.2~-5 
checking 6.2-1 
expedited flow 6.2-5 
identifiers 6.2-5 
initialization 6.2-5 
normal flow 6.2-5 
wrapping 6.2-5 
session cryptography key 6.2-2 


session-level pacing 6.2-1) 6.2-4) 6.2-5;, 


6.2-20, 6.2-21 
FSM_PAC_RQ.RCV 6.2-21 
FSM_PAC_RQ_SEND 6.2-20 
IPR 6.2-6 
pacing count 6.2-6 
PI 6.2-5, 6.2-6 
stages 6.2-5 
window size 6.2-5 
session seed 6.2-2; 6. 2-5 
structure 
interrelation of TC. SEND and 
TC.RCV 6.2-4 
relation to the half-session 6.2-1 
TC initialization calling tree 6.2-7 
TC RCV calling tree 6.2-7 
TC SEND calling tree 6.2-7 
TO.RCV 6.2-4 
TC.SEND 6.2-4 
transmission header (TH) 6.2-3 
TS profile 1 6.2-5 
TS profile 7 6.2-5 
transmission control calling trees 6.2-7 
TC initialization calling tree 6.2-7 
TC RCV calling tree 6.2-7 
TC SEND calling tree 6.2-7 
transmission control control block 
(TCCB) 6.2-5 
transmission header (TH) 2-15, 2-16, 2-32 
session control 6.2-3 
transmission services (TS) profiles F-5 
transport characteristics 2-3 
See also wode, LU 
tree 
See logical unit of work (LUN), distrib- 
uted 
truncation of logical records 2-12, 2-14 
TRY_TO_RCV_SIGNAL procedure 6.1-22 
referenced by 
PROCESS LU_LU_SESSION 6.0-4 
TS (transmission services) 
profiles F-5 
Usage field F-5 
TS (transmission services) profile 
in BIND 4-20 
TS profile 
See profiles 


TS profile 1 6.2-5 


TS profile 7 6.2-5 


TS Usage field 
in BIND 4-21 


two-way alternate send/receive protocol 


mode 
Type-A symbol string E-1 
Type-AE symbol string E-1 
Type-6 symbol string E-1 
Type-6R symbol string €E-1! 
type of session termination 

implied by CLEANUP 4-12 

specified in CTERM 4-12 

specified in TERM-SELF 4-12 
Type-USS symbol string E-1 
type, node 1-3 

See also node 
type, PU 1-5 

See also PU type 


UNBIND 2-16, 2-37, E-15 
See also UNBIND SESSION 
session failure 2-32 
UNBIND FAILURE (UNBINDF) 4-13, E-15 
UNBIND_PROTOCOL_ERROR_PROC procedure 3-65 
referenced by 
PROCESS_PS_TO_RM_RECORD 3-21 
UNBIND_PROTOCOL_ERROR structure A-28 
referenced by 
PS_PROTOCOL_ERROR 5.0-15 
UNBIND_ PROTOCOL _ERROR_PROC 3-65 
UNBIND_RQ_RCV_RECORD structure A-23 
referenced by 
BUILD_AND_SEND_UNBIND_RSP 4-70 
FSM_ STATUS 4-95 
-PROCESS_ RECORD_FROM_NNM 4-50 
PROCESS UNBIND_RQ 4-91 
UNBIND _RQ_SEND_ RECORD structure A-19 
referenced by 
BUILD _AND_ SEND_ UNBIND_RQ 4-69 
UNBIND_RSP_ RCV_ RECORD structure A-23 
referenced by 
FSM_STATUS 4-95 
PROCESS _RECORD_FROM_NNM 4-50 
PROCESS_UNBIND_RSP 4-92 
UNBIND_RSP_SEND_RECORD structure A-19 
referenced by 
_ BUILD LAND_SEND_UNBIND_RSP 4-70 
UNBIND SESSION (UNBIND) 4-28, E-15 
UNBINO without CTERM 4-12 
UNBINDF E-15 
See also UNBIND FAILURE 
undefined protocol machine (UPMH), definition 
of 1-6 
underscores, separating multiple terms of a 
name phrase 1-5 
Unformatted Data Structured Data Sub- 
field E-16 
uninterpreted LU name 46-5 
See also LU name 
identity transformation of 4-5 
in CINIT 4-10 
in INIT-SELF 4-9 
interpretation of 4-5 
Uninterpreted Name Session Key E-23 
unit of sork 
See syne point, logical unit of work 


See half-duplex flip-flop send/receive 
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UNSUCCESSFUL_SESSION_ACTIVATION proce- 
dure 3-66 
referenced by 
ACTIVATE_SESSION_RSP_PROC 3-23 
UPDATE_FSMS procedure 6.1-42 
referenced by 
DFC_RCV_FSMS 6.1-24 
GENERATE_RM_PS_INPUTS 6.1~-31 
UPM (undefined protocol machine), definition 
of 1-6 
UPM_ATTACH_LOG procedure 5.0-18 
referenced by 
ATTACH_ERROR_PROC 5.0-10 
UPM_EXECUTE procedure 5.0-17 
referenced by 
PS_INITIYALIZE 5.0-6 
UPM_MAPPER procedure 5.2-46 
referenced by 
MC_CONFIRM_PROC 5.2-21 
MC_DEALLOCATE_PROC 5.2-23 
MC_PREPARE_TO_RECEIVE_PROC 5.2-26 
MC_SEND_DATA_PROC 5.2-38 
MC_SEND_ERROR_PROC 5.2-40 
PROCESS DATA_COMPLETE 5.2-33 
PROCESS ERROR_OR_FAILURE_RC 5.2-3) 
RCVD_SVC_ERROR_PURGING 5.2~-42 ie 
RCVD_SVC_ERROR_TRUNC_NO_TRUNC 5.2-41 
RECEIVE INFO_PROC 5.2-30 
SEND_SVC_ERROR_PURGING 5.2-45 
UPM_RETURN_ PROCESSING procedure 5.0-18 
referenced by 
DEALLOCATION_CLEANUP_PROC 5.0-13 
URC 
See user request correlation (URC) 
URC Session Key E-23 | 
user-application node 1-3, 1-4 
See also node 
User Data field 
in BIND 4-23 
user ID, security 
See conversation-level security 
user of LU 2-1 
user request correlation (URC) 4-5 
in BIND 4-25 _ 
in CINIT 4-10 
in INIT-SELF 4-9 
tm TERM-SELF 4-11 


LY] 


VERB_PARAMETER_CHECK procedure 5.4-48 
referenced by 

SOURCE_SESSION_LIMIT_PROC 5.4-46 

VR-ER Mapping Data Control Vector E-22 


WAIT_FOR_CONFIRMED_PROC procedure 5.1-59 
referenced by 
COMPLETE_CONFIRM_PROC 5.1-29 
DEALLOCATE_CONFIRM_PROC 5.1-33 
PREPARE TO_RECEIVE_CONFIRM_PROC 5.1-41 
WAIT _FOR_RM_REPLY procedure 5.1-60 
referenced by 
ALLOCATE_PROC 5.1-11 
OBTAIN_SESSION_PROC 5.1-38 
WAIT_FOR_RSP_TO_RQ_TO_SEND_PROC proce- 
dure 5.1-61 
referenced by 
REQUEST_TO_SEND_PROC 5.1-23 
WAIT_FOR_SEND_ERROR_DONE_PROC proce- 
dure 5.1-62 
referenced by 
DEALLOCATE_ABEND PROC 5.1-32 
SEND_ERROR_IN_RECEIVE_STATE 5.1~-54 
WAIT_PROC procedure 5.0-13 
referenced by 
PS _VERB_ROUTER 5.0-11 
nindow size 
session-level pacing 6.2-5 
winner, contention 
See bracket, first speaker 
workstation 
See peripheral node to peripheral node 
communication 
See peripheral node to subarea node commu- 
nication 
See resource, local 


X06F1 procedure 5.4-57 


YIELD_SESSION structure A-30 
referenced by 
SUCCESSFUL_SESSION_ACTIVATION 3-63 
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TERMINOLOGY: ACRONYMS AND ABBREVIATIONS 

ACT activate 

ACTLU ACTIVATE LOGICAL UNIT 

API application programming interface 

ASCII American Standard Code for Informa- 
tion Interchange 

BB Begin Bracket 

BBI Begin Bracket indicator 

BC Begin Chain 

BCI Begin Chain indicator 

BETB between brackets 

BIND BIND SESSION 

BINDF BIND FAILURE 

BIS BRACKET INITIATION STOPPED 

BIU basic information unit 

CD Change Direction 

CDI Change Direction indicator 

CEB Conditional End Bracket 

CINIT CONTROL INITIATE 

CLEANUP CLEAN UP SESSION 

CNOS change number of sessions 

COPR control operator services 

cos class of service 
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CP 


CR 


CRV 


CsI 


CT 


CTERM 


DACTLU 


DES 


DFC 


DIA 


DLC 


DLU 


DR1 


DRIT 


DRe 


DR2I 


DSU 


EC 


ECHOTEST 


ECT 


ED 


Terminology: 


control point 


conversation resource 


CRYPTOGRAPHY VERIFICATION 


Coda Selection indicator 


correlation table 


CONTROL TERMINATE 


DEACTIVATE LOGICAL UNIT 


Data Encryption Standard 


data flow control 


Document Interchange Architecture 


data link control 


destination LU 


Definite Response 1 


Definite Response 1 indicator 


Definite Response 2 


Definite Response 2 indicator 


distribution service unit 


End Chain 


ECHO TEST 


End Chain indicator 


Enciphered Data 


Acronyms and Abbreviations T-1 


EDI Enciphered Data indicator INIT initiate 


EFI Expedited Flow indicator INIT-SELF INITIATE-SELF 
ERI Exception Response indicator IPR ISOLATED PACING RESPONSE 
ERP error recovery procedure(s) 
LIC last in chain (-~BC, EC) 
EXP expedited 
LL logical record length (prefix) 
EXR EXCEPTION REQUEST 
LLID logical record length and GDS ID 
(prefix) 
FDX full-duplex LNS LU network services 
FF flip-flop LU logical unit 
FI Format Indicator LUCB LU control block 
FIC first in chain (BC, -EC) LUSTAT LOGICAL UNIT STATUS 
FM function management LUW logical unit of work 
FMD function management data 
MC mapped conversation 
FMH FM header 
MCR mapped conversation record 
FMP FM profile 
MGR manager 
FSM finite-state machine 
MIC middle in chatn (~BC,~EC) 
FSP first speaker 
MSG message 
GDS general data stream MU message unit 
HDX hal f-duplex NAU network addressable unit 
HDX-FF HDX flip-flop NC network control 
HS half-session NEG negative 
HSID half-session identification NG no good 
NNM nodal NAU manager 
ID identifier, identification 
NS network services 
ILU initiating LU (LU sending 


INIT~-SELF ) 
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NTWK 


PAC 


PC 


PD 


PDI 


PI 


PIP 


PIU 


PLU 


POS 


“PRI 


PS 


PTR 


QRI 


RCB 


netuork 


only in chain (BC, EC) 


origin LU 
primary 
Pacing Request, Pacing 


(value of PI in RH) 


path control 


Padded Data 


Padded Data indicator 


Pacing indicator 


Response 


program initialization parameters 


path information unit 


primary LU 


positive 


primary 


presentation services 


pointer 


physical unit 


queue 


Queued Response 


Queued Response indicator 


receive, receiving 


return code 


resource control block 
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RCV 


REQECHO 


RES 


RESYNC 


RH 


RQ 


RQD 


RQE 


RQN 


RRI 


RSP 


RTI 


RTR 


SCS 


SO 


SDI 


SEC 


SESS 


SESSEND 


SESSST 


Terminology: 


receive 


REQUEST ECHO TEST 


resource(s ) 


syne point resynchronization serv- 
ice TP 


request/response header 


request 


RQ indicating definite-response 


required 


RQ indicating 
requested 


exception-response 


RQ indicating no response required 


Request/Response indicator 


response 


Response Type indicator 


READY TO RECEIVE 


request/response unit 


secondary, sending 


session control block 


SNA character string 


Sense Data Included 


Sense Data Included indicator 


secondary 


SeSS10n 


SESSION ENDED 


SESSION STARTED 


Acronyms and Abbreviations 


T-4 


SETCV 


SIG 


SLDLM 


SLU 


SNA 


SNADS 


SNASVCMG 


SNF 


SON 


SQN 


SS 


SSCP 


SSLS 


svc 


SYNCPT 


SET CONTROL VECTOR 


SIGNAL 


session-limit data-lock manager 


secondary LU 


Systems Network Architecture 


SNA Distribution Services 


SNA services manager (LU-LU session 
mode name) 


sequence number field 


session outage notification 


sequence number 


session services 


system services control point 


source-LU session-limit services 


service 


synchronization point 


TC 


TCB 


TCCB 


TERM 


TERM-SELF 


TH 


TLU 


TP 


TS 


TSLS 


TSP 


UNBIND 


UNBINDF 


UPM 


URC 
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transmission control 


transaction control block 


transmission control control block 


terminate, terminating, termi- 


nation, terminal 


TERMINATE-SELF 


transmission header 


terminating logical unit (LU send- 
ing TERM) 


transaction program 


transmission services 


target-LU session-limit services 


TS profile 


UNBIND SESSION 


UNBIND FAILURE 


undefined protocol machine 


user request correlation 
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